Production deployment for Dropbox Sign API

Your integration is working, your testing is complete, and you're almost ready to put it in the hands of real users. Before you go live, there are a few final checks to make.

For many integrations, getting to production is simpler than you might expect. Whether you need app approval depends on the type of integration you've built.

In this module, you'll learn how to prepare your integration for production, understand when approval is required, and launch with confidence.

Understanding app approval

Before certain integrations can be used in a production environment, Dropbox Sign requires an approval process.

App approval helps ensure that integrations using embedded or OAuth functionality meet Dropbox Sign requirements and provide a reliable user experience.

The approval process also helps identify potential issues before applications are deployed to production users.

When is approval required?

Not every integration requires approval.

Approval is required when an application uses:

Embedded workflows

Including:

• Embedded signing

• Embedded requesting

• Embedded templates

These workflows allow users to complete Dropbox Sign actions directly within your application.

OAuth applications

Approval is also required when your application authenticates users through Dropbox Sign OAuth.

Unlike API key authentication, OAuth allows users to authorize your application to access Dropbox Sign on their behalf. Because these integrations involve user authorization and permission scopes, they require additional review before moving to production.

Note

Integrations that use OAuth must go through support-assisted approval. The self-publish option isn't available for OAuth applications.

When approval is not required

Many standard API integrations can move to production without app approval.

For example:

• Server-to-server integrations

• Basic API request automation

• Non-embedded workflows

If your integration only uses API keys and standard API endpoints, approval may not be necessary.

Approval options

Dropbox Sign offers two approval paths for embedded API apps:

• Self-publish

• Support-assisted approval

The right option depends on the type of integration you've built, its complexity, and the level of support required.

Self-publish

Self-publish allows eligible embedded API apps to move to production without a manual review from Dropbox Sign Support.

It's a good fit when:

• Your app uses an embedded workflow.

• Development is complete.

• The full user workflow has been tested.

• Everything is working as expected.

• You don't need additional implementation guidance before going live.

Support-assisted approval

Support-assisted approval provides additional guidance throughout the review process.

It's required for OAuth applications and may also be the right choice when:

• Your workflow is complex.

• Multiple systems are involved.

• Your team wants implementation support.

• Questions arise during testing.

Before choosing either approval path, make sure your integration is complete and ready for production. Be prepared to provide details such as your client ID, callback URLs, and a demonstration of the user workflow.

Preparing for approval

Before submitting an application for approval, verify that the integration is functioning as expected.

Consider the following questions:

• Can users successfully complete the workflow?

• Are embedded experiences functioning correctly?

• Are callback events being received and processed?

• Are domains configured correctly?

• Have all required app settings been completed?

The more thoroughly an application is tested before submission, the smoother the approval process is likely to be.

Production readiness checklist

Before launching an integration into production, review the following checklist.

Application readiness

• App approved (if required)

• Domains verified

• Callback URLs configured and using HTTPS.

Security readiness

• API keys secured

• Authentication tested

• Access controls reviewed

Operational readiness

• Support teams informed

• Documentation updated

• Maintenance responsibilities assigned

Deployment readiness

• test_mode has been removed from backend API requests.

• skipDomainVerification has been removed from client-side embedded workflows.

• Production workflows have been validated.

• Monitoring has been configured.

• Ownership has been documented.

Note

Leaving test_mode or skipDomainVerification enabled after publishing is one of the most common causes of production issues. Before going live, verify that both settings have been removed from your integration.

Common launch issue

My integration worked in testing but not in production

One of the most common causes is an incomplete production readiness process.

Before troubleshooting:

• Verify approval requirements have been completed.

• Confirm domains have been verified.

• Review callback configurations.

• Ensure test_mode has been removed from backend API requests.

• Ensure skipDomainVerification has been removed from client-side embedded workflows.

• Confirm production credentials are being used.

Many production issues can be resolved by reviewing these foundational configuration settings.

Best practice

Treat production deployment as a process, not a single event.

Successful teams typically:

• Test thoroughly before launch.

• Document configuration decisions.

• Assign ownership responsibilities.

• Establish monitoring procedures.

• Review production readiness before every major release.

This approach helps reduce risk and supports long-term integration success.

Your integration is ready to go live, and you've completed the final checks before launch.