Skip to content
Feny
Sign inRegister
Create your business
Your business grows with you
Create your business in 5 minutesOnline booking, website and clients — in one place
Sign inRegister
Create your businessNeed help?We are always nearby
© 2026 Feny. All rights reserved.

First integration

Move from a test tenant to production deliberately.

The same contract is used in both environments, but credentials, tenant data, database and reset policy must remain separate.

Get startedView API reference

Integration sequence

  1. 1. Prepare a sandbox

    Use the dedicated sandbox API origin, test tenant and credentials. Populate only synthetic services, staff and guest contacts.

  2. 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. 3. Read before writing

    Resolve a current published service and free slot, then send the returned identifiers unchanged in the booking request.

  4. 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. 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. 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

http
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.example

Sandbox 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

ScopeAccessPermitted work
catalog.readReadRead the current published service, location and specialist catalog.
availability.readReadRead bounded current free slots.
booking.createWriteCreate a partner guest booking with consent, external_reference and Idempotency-Key.
booking.manageWriteRead and change only bookings owned by the application using opaque pbr_ references.
webhooks.manageWriteConfigure, 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.
Getting started | Feny Developers