To list an Extension App in the Docusign App Center, your app must pass a Docusign-run publication review against the App Center publishing guidelines and the App Center Terms. In practice that means a valid JSON manifest declaring a supported extension type, OAuth 2.0 Authorization Code Grant for public distribution, a working external service behind the manifest's proxyBaseUrl, complete listing copy and assets, and an app that survives Docusign's functional, security, and quality checks before the review team flips it live.

This is the operational guide we hand to ISVs we work with at fluidlabs after the strategy article on why ISVs should build on the App Center. It is the part that decides whether your submission ships in weeks or stalls in review.

Where the actual listing requirements live

Docusign splits the rules across three documents, and you need all three open when you build:

1. The App Center publishing guidelines - the operational checklist Docusign reviewers run against.
2. The Docusign App Center Terms - the legal envelope. Section 3.2 reserves Docusign's right to reject any Extension App that does not offer sufficient value, meet minimum functionality, performance, and quality standards, or comply with the Publication Guidelines.
3. The App manifest reference - the machine-readable contract your submission has to match.

The Terms also flag a separate gate that surprises first-time submitters: Docusign "may also require Your Extension App to undergo a security review and/or compliance review." For anything that touches customer data, assume that gate fires.

What is an Extension App, in one paragraph

An Extension App is a Docusign-registered integration that plugs an external service into Docusign IAM at well-defined hook points - data lookups, file archival, custom field verification, and so on. The app itself is a manifest plus a service you host. Docusign calls your service over HTTPS at the action endpoints declared in the manifest, using OAuth tokens it acquires through your configured connection. The App Center is the storefront where customers discover and install that integration.

Pick the extension type first - it shapes everything else

Docusign documents the full set on the Supported extensions page. The ones reviewers see most often:

• Data IO - read or write structured records to your system of record (e.g. pull a Customer record into an envelope, or push form responses back).
• Connected Fields - real-time custom verification of envelope fields against your system of record, used to drive NIGO-to-STP workflows (background).
• Data Verification - pre-built verification for canonical types like address or bank account.
• File Archive - receive the completed agreement PDF and store it somewhere durable.
• File Output Tabular Format - emit structured tabular extracts of agreement data.

Docusign ships reference implementations on GitHub with working manifests for the most common types. Start from one. We have seen first submissions handcrafted from scratch fail validation on field-name typos that a forked reference repo would have caught in five minutes.

Also decide distribution before you submit. The private distribution doc lays out the trade-off: a private app skips the App Center storefront entirely and is restricted to an allowlist of Docusign account IDs you supply at publish time. If only your own customers will ever install the app, private is faster and the security review surface is smaller. Public is the path that triggers the full listing-requirements review described in the rest of this article.

The manifest is the contract reviewers actually read

The Extension App manifest is a single JSON document. The reference implementations blog and the manifest reference confirm the top-level shape - the bits reviewers inspect first:

Three details consistently trip up first submissions:

• termsOfServiceUrl and privacyUrl must resolve to public, app-specific pages. A 404 or a generic corporate privacy page is a rejection. Reviewers click them.
• Action contracts are strict. Each extension type defines required action names and request/response schemas. Skipping a required action or returning a payload that fails the contract validator is the most common technical failure we see.
• proxyBaseUrl must be a public HTTPS endpoint with a valid certificate, not an ngrok tunnel. Tunneled URLs are fine for local testing but get caught the moment review traffic stops resolving.

OAuth: what "passes" looks like

The authorization rules are not subjective. Per the Authorization docs, "If you select Public for your distribution type, your extension app will use Authorization Code Grant by default." Docusign's OAuth practical guide reinforces it: Authorization Code Grant is the required standard for all public Extension Apps so user identity is tracked and credentials stay protected. Client Credentials Grant is reserved for private apps where there is no user context.

For a public listing, that means your external service must implement:

• A consent / authorization screen that names your app, the customer's tenant, and the scopes being granted in plain language.
• A /token endpoint that issues short-lived access tokens and rotating refresh tokens.
• Correct handling of refresh failures so installs do not silently break when a refresh token expires.

Reviewers test the consent flow. If the screen does not clearly say which third-party data your app will read or write on the user's behalf, expect feedback.

Listing copy, assets, and publisher info

The App Center preview page is the customer-facing surface. It enumerates what an end user sees: the name and short and long descriptions, publisher and contact information, the icon, and screenshots. Treat the listing like a product page, not documentation.

Field-by-field guidance we give clients:

• Name - the actual product name, not "Acme for Docusign" suffix theater. Reviewers reject generic or trademark-confusing names.
• Short description - one sentence that answers "what does this do." This is the snippet shown in App Center search results.
• Long description - lead with the workflow problem solved, not your company history. Name the IAM surface (Workflow Builder step, envelope field, etc.) where the app activates.
• Icon and screenshots - follow the spec on the Update App Center listing page. Screenshots that show the app actually running inside Docusign convert; marketing collages get flagged.
• Publisher details and support contact - must be monitored. The App Center Terms require you to operate a Data Incident management program; an unmonitored info@ address fails that bar implicitly the first time anything goes wrong.

The submission and review workflow

The canonical sequence, taken from the App Center docs:

1. Confirm the app meets the publishing guidelines.
2. Complete the app submission form in the Developer Console.
3. Work with the Docusign app review team on feedback.
4. After approval, publish the app to the App Center.

Docusign's separate application review process page describes the stages partner submissions move through. There is no public SLA in calendar days; plan in weeks, not days, and longer if a security review is triggered. The pattern we see: technical review starts within days of a complete submission, but the round-trip on substantive feedback - especially anything that touches the OAuth flow or the action contracts - is what extends the timeline.

If you also need to trigger Docusign Workflow Builder runs from a source system as part of the integration, do that with a hardened relay rather than rebuilding HMAC, retries, and replay protection yourself - that is exactly what Baton exists for, and it keeps your Extension App scoped to the agreement-surface work reviewers actually want to see.

Why apps get rejected (the patterns we see)

From submissions we have either led or audited:

• Action contract drift. The manifest declares an extension type, but at least one action returns a payload the contract validator rejects. Almost always caused by hand-edits after forking a reference implementation.
• OAuth scope sprawl. The connection requests scopes the app never uses. Reviewers ask why, you cannot justify, you go back and trim.
• Privacy and terms URLs that resolve to a corporate boilerplate page with no mention of the Extension App or the data it processes.
• Screenshots that do not show the app in Docusign. Marketing renders, slide decks, abstract diagrams. Reviewers want to see the actual extension activating in a real envelope or workflow.
• Listing copy that does not say where the app runs. "Integrates with Docusign" is not enough. Name the surface: an action in Workflow Builder, a Connected Fields verification on an envelope, a File Archive destination triggered on envelope completion.
• An unmonitored support contact combined with a fragile webhook handler. The first install that 500s in production is the one that escalates back to Docusign, and a slow human response damages your standing for future updates.

None of these are exotic. They are also the same failure modes that show up in our build vs buy framework - the operational debt that makes an Extension App a real product instead of a manifest.

FAQ

Do I need to be a Docusign Partner to list in the App Center? You submit Extension Apps through the Developer Console, and Docusign reserves the right to require additional reviews per the App Center Terms. Public listing is the partner-facing path; private distribution lets you ship to an allowlist of account IDs without going through the public storefront.

Can a public Extension App use Client Credentials Grant? No. Per the Authorization docs, public apps default to and require Authorization Code Grant. Client Credentials Grant is for private apps with no user context.

Is there a fixed review timeline? Docusign does not publish a public day-count SLA. Plan in weeks, longer if your data flows trigger a security or compliance review.

Can I update the listing after it is live? Yes. The App Center listing form is where you edit copy, icons, and screenshots; substantive manifest changes follow the same review path as a new submission.

What happens if Docusign retests my app after listing? The App Center Terms allow Docusign to periodically test and evaluate listed Extension Apps and to remove apps that no longer meet the Publication Guidelines. Treat the launch as the start of an operating commitment, not the end of a project.

Next step

If you are mapping a real Extension App against this checklist and want a second pair of eyes before you hit submit - on the manifest, the OAuth flow, the listing copy, or the rejection risks specific to your extension type - book a working session with the fluidlabs team. More background on the IAM surface and adjacent integration patterns lives in the fluidlabs resources library.