Going live

Before you ask for production credentials

1. Your sandbox integration completes the consent flow, renews credentials, reads and writes, and handles a cancelled consent.
2. A disconnected or suspended connection stops your app cleanly, and a reconnect from inside your product works.
3. Every write sends an Idempotency-Key, and a retry after a timeout does not duplicate.
4. You handle 429 by waiting until the RateLimit reset, and you spread syncs across businesses rather than running them at once.
5. Your app asks only for the permissions it uses, and works when a permission is reduced.
6. You store dates of birth and addresses only if you asked for staff details, and you can delete a business's data on request.

What Shiftly needs from you

• Your production return addresses, each starting with https://. Shiftly only sends people back to an address on the list.
• A contact email that is watched. Shiftly uses it to reach you about your app.
• Your app's name, website and a square logo. The business sees these on the consent screen and on their Connected apps page, and Open [your app] sends them to your website.
• The signed partner agreement.

What Shiftly gives you

A production client id and a client secret, shown once. Store the secret as you would a password. If it is lost or exposed, ask Shiftly to rotate it; the old secret keeps working for an overlap you agree on, up to seven days, so you can switch over without downtime.

Production apps start with a connection limit while they are new. When a business is told your app can't take new connections yet, ask Shiftly to raise the limit.

After launch

• Watch for 403 connection_suspended and connection_disconnected answers and renewals that answer invalid_grant, and tell the business in your product how to reconnect.
• Watch for Deprecation and Sunset headers, and read the Changelog when they appear.
• Quote the Shiftly-Request-Id when you report a problem.