FenyIntegration sequence
1. Prepare a sandbox
Use the dedicated sandbox API origin, test tenant and credentials. Populate only synthetic services, staff and guest contacts.
2. Create a least-privilege application
Enable only the required scopes. Confirm write scopes explicitly and set selected-location, origin and IP restrictions where applicable.
3. Read before writing
Resolve a current published service and free slot, then send the returned identifiers unchanged in the booking request.
4. Make writes replay-safe
Use a fresh Idempotency-Key per logical operation. For a cancel or reschedule, retrieve the booking first and send expected_version.
5. Verify delivery
Subscribe a public HTTPS endpoint, store the one-time signing secret in a server-side vault, then persist webhook event ids before side effects.
6. Promote intentionally
Issue a new production key and signing secret. Do not reuse sandbox credentials, tenant handles, bookings or webhook URLs as a migration mechanism.
Server-side authorization example
GET /api/partner/v1/catalog?locale=en&limit=25 HTTP/1.1
Authorization: Bearer fnx_test_example_key_not_a_real_credential
Origin: https://partner.exampleSandbox and production are separate
Sandbox (TEST)
A dedicated database, tenant, API origin and credential issuer are required. Payments are disabled, data is synthetic only, and the reset policy is explicitly DAILY or ON_DEMAND.
Production (LIVE)
Create a separate production application, credentials and webhook secret after the integration is ready. Production is never a fallback for sandbox configuration.
Authentication and scopes
| Scope | Access | Permitted work |
|---|---|---|
| catalog.read | Read | Read the current published service, location and specialist catalog. |
| availability.read | Read | Read bounded current free slots. |
| booking.create | Write | Create a partner guest booking with consent, external_reference and Idempotency-Key. |
| booking.manage | Write | Read and change only bookings owned by the application using opaque pbr_ references. |
| webhooks.manage | Write | Configure, pause, replay and rotate the application webhook endpoint from the owner Control Center. |
Keep these values out of browser storage
- Partner API keys and webhook signing secrets.
- Raw Idempotency-Key values if they carry business meaning or customer data.
- Webhook payload archives that contain an opaque booking reference and operational schedule details.
Support and promotion policy
- Before production promotion, verify the current scoped application, allowed origins/IPs, selected locations, webhook receiver and retry behavior in sandbox.
- For an integration issue, provide the environment, endpoint, UTC timestamp, HTTP status and X-Request-Id. Do not include a credential, signing secret, full webhook payload or customer contact data.
- This public documentation does not promise response or uptime targets. Use the static status page as a release-contract reference and retain bounded retries in the integration.