Go-live checklist

Work through this checklist in sandbox before you choose Request production access in the Partner Portal. Rehabify reviews your request against the same points.

Before you request production access

Keys and security

• API keys are loaded from environment variables or a secret manager, never hard-coded, and are never sent to browsers, mobile apps or URLs.
• Logs never contain API keys, webhook signing secrets, Authorization headers or clinical.notes. Log the X-Request-Id response header instead.
• You know how to rotate and revoke keys without downtime.

Creating referrals

• You capture the patient's consent before referring and send consent.granted: true, ideally with method, captured_at and privacy_notice_version.
• Every POST /partners/referrals carries an Idempotency-Key. You retry network errors, 429, 500 and 503 with the same key, and use a new key when the body changes.
• You send your own partner_reference, and handle 409 duplicate_partner_reference by fetching error.existing instead of creating a new referral.
• You handle 422 validation_error (use param to show which field is wrong) and 422 consent_required.
• You handle a rejected referral (test it with the magic number +2348000000004, which returns 422 patient_ineligible).
• You store the referral's id and tracking_code, and give the patient links.whatsapp_intake_url.

Reading data

• You can fetch a referral by id, tracking_code and partner_reference.
• List calls follow next_cursor until has_more is false.
• Your code treats every unknown or optional value as possibly null.

Webhooks

• Your endpoint uses https://, is publicly reachable, and answers 2xx within 10 seconds. Slow work is done asynchronously.
• You verify X-Rehabify-Signature against the raw body, with a 300-second tolerance and a constant-time comparison.
• You deduplicate on the event id, because delivery is at-least-once.
• You use data.sequence (or referral.updated_at) to ignore stale or out-of-order events.
• You handle all nine referral.* event types and ping, and ignore types you don't recognise.
• You fetch patient details with GET /partners/referrals/{id} when you need them. Webhooks never contain patient data.

Rate limits and errors

• You respect Retry-After on 429 rate_limit_exceeded and back off with jitter.
• You branch on error.code, not on error.message.

Scenarios to rehearse in sandbox

Switching to live

Once Rehabify approves production access:

1. Create a sk_live_ key in Developers → API keys. You can't create one before approval.
2. Set your live webhook endpoint in Developers → Webhooks, and store the live signing secret. It's different from the sandbox secret.
3. Deploy the live key and secret to production. The base URL, https://api.physioaroundme.com/v1, doesn't change.
4. Check that responses carry X-Rehabify-Environment: live.
5. Remove any magic phone numbers or test data from your production flows. In live, Rehabify contacts every referred patient.

Keep your sandbox keys for staging and regression testing. Sandbox and live data never mix.

After go-live

• Watch for failed webhook deliveries in the portal, and resend them once your endpoint is healthy. Resent events keep the same event id.
• Reconcile commissions monthly with GET /partners/commissions.
• If production access is suspended, live calls return 403 production_access_required. Contact partners@physioaroundme.com.