Inbound Forms

BytePhase has ready-made receivers for several providers. You point the provider’s webhook at a BytePhase URL; the receiver understands that provider’s payload and turns it into a lead or self check-in through the same pipeline as every other submission.

POST /api/integrations/ingest/{adapter}

`{adapter}`	Provider type to create in BytePhase	Verification	Key travels in
`typeform`	Typeform	HMAC signature (optional)	Header
`jotform`	JotForm	None	Header
`tally-so`	Tally.so	HMAC signature (optional)	Header
`indiamart`	IndiaMART	None	URL
`justdial`	Justdial	None	URL
`form`	Website / REST API	None	Header
`canonical`	Website / REST API	None	Header

form and canonical are for your own code and are covered in Custom Integrations. An adapter name not in this list returns 404 unsupported_adapter.

Typeform, JotForm and Tally.so

These three post their own field names (“What’s your name?”, q3_phone, …), so BytePhase cannot create a record until you have mapped the form once.

In BytePhase, Settings → Integrations → choose the matching provider (Typeform, JotForm or Tally.so). The wizard’s Connect step shows a Webhook URL — “Paste this URL into the provider’s webhook settings. It includes your key — copy it now.” For Typeform and Tally.so it also shows a Signing secret.
In the provider, add a webhook and paste that URL. It has the form:
```
https://harbor-repair.api.bytephase.com/api/integrations/ingest/typeform?token=bp_your_api_key
```
The key travels as the token query parameter because these providers cannot set headers. Treat the whole URL as a secret. (Your own code should send the key as a header instead — see Authentication.)
Submit the form once. The submission arrives as received and is parked. In BytePhase, open the integration’s forms: the fields the provider sent are detected for you. Map them — at minimum name and one of email / mobile_number — choose the destination (lead or self_checkin), activate the form, and retry the parked submission.
From then on, every submission is created automatically.

The provider’s form identifier is used as the form_id, so one integration can carry several forms, each mapped separately.

Destination. You can pin the destination in the webhook URL instead of in the form settings, with ?destination=lead or ?destination=self_checkin.

Idempotency. Each receiver derives an Idempotency-Key from the provider’s own submission id, so a webhook the provider retries never creates a second record. See Idempotency.

Multiple-choice answers arrive as their labels, joined with commas. File uploads arrive as URLs. Hidden fields (Typeform) are included.

Verifying signatures

Typeform and Tally.so can sign each webhook. It is optional but recommended: without it, anyone who learns the URL and key can post submissions.

Copy the Signing secret from the wizard’s Connect step — “Paste this into the provider’s webhook secret field so we can verify each delivery.”
Paste it into the provider’s webhook settings (Typeform: turn on Secret on the webhook; Tally: turn on Signing secret), then save.

Once a secret exists on the integration, every request must carry a valid signature or it is rejected with 401 invalid_signature. Typeform sends it as Typeform-Signature, Tally as Tally-Signature; both are an HMAC-SHA256 of the raw body, base64-encoded. BytePhase verifies them for you — you do not need to implement anything.

JotForm does not sign webhooks, so the key is the only credential; keep the webhook URL private.

IndiaMART and Justdial

IndiaMART and Justdial are Indian marketplaces — IndiaMART for business-to-business enquiries, Justdial for local-business listings. They list only Indian businesses, so the provider types are offered to workspaces in India. Their panels accept a URL and nothing else — no headers — so the key is part of the URL. That is the only place on the API where a key belongs in a URL.

An IndiaMART key is accepted only by the IndiaMART receiver, and a Justdial key only by the Justdial receiver; any other combination returns 403 integration_not_permitted. Because the URL is the whole credential, treat it as a secret: do not paste it anywhere but the provider’s panel, and rotate the key if it is ever exposed.

IndiaMART

Settings → Integrations → add an integration with the provider type IndiaMART. Copy the key.

In your IndiaMART seller panel, configure the Lead Manager Push API with:

https://harbor-repair.api.bytephase.com/api/integrations/ingest/indiamart/bp_your_api_key

Every enquiry IndiaMART pushes becomes a lead with the source “IndiaMART”: name, email, mobile (split into the national number and the Indian dialling code), phone, the subject and message as the comment, and the sender’s address. Everything else IndiaMART sends — query id and type, company, product, category, alternate contacts, call duration — is kept on the lead as custom fields.

IndiaMART’s unique query id is used as the idempotency key, so a re-push does not duplicate the lead. No form mapping is needed.

Justdial

Settings → Integrations → add an integration with the provider type Justdial. Copy the key.
Give your Justdial account manager the URL:
```
https://harbor-repair.api.bytephase.com/api/integrations/ingest/justdial/bp_your_api_key
```
Justdial delivers each lead as an HTTP GET with the details in the query string; the receiver also accepts POST.
Every enquiry becomes a lead with the source “Justdial”: name (with prefix), mobile (split into the national number and the Indian dialling code), phone, email, area, city and pincode as the address, and the category as the comment. Any other parameter Justdial sends is kept as a custom field, so nothing is dropped if their format differs from what we expect.

Justdial’s lead id, when present, is the idempotency key. When it is absent, a fingerprint of the enquiry for the day is used instead, and the workspace’s duplicate rule still catches a repeat. No form mapping is needed.

Responses and troubleshooting

Receivers return the standard intake response — 201 completed, 200 duplicate or 202 received — and the standard error object. Most providers show the response status in their webhook logs; the BytePhase submission log shows every delivery on our side with its request id.

Status	Meaning
`202 received`	Form not mapped or not activated yet. Map it and retry.
`401 invalid_signature`	The signing secret in the provider does not match the one in BytePhase.
`403 integration_not_permitted`	Wrong key type for this receiver (for example an IndiaMART key on the Justdial URL).
`404 unsupported_adapter`	Typo in the adapter name.
`422 unreadable_submission`	The payload is not in the format the receiver expects. Check the provider’s webhook format setting.
`422 validation_failed`	Mapped fields do not satisfy the rules — usually no `name`, or neither `mobile_number` nor `email`.

bytephase.com/integrations/typeform — the Typeform integration page with screenshots.
How self check-in works in BytePhase — what a booking form creates, from the customer’s and the shop’s side.
How it works — the end-to-end picture for non-developers.