ovbq QR code API and webhooks
Use the API for supported QR code operations. Use a webhook to send a supported ovbq event to a destination you control. Requests and event notifications are separate tools, with separate access.
This reference describes owner tools. Team membership does not grant credentials or the right to operate another owner's API, webhooks or feeds. Check your current plan and the controls in Developer access.
Send a supported request
Requests use HTTPS under /api/v1. Put the key in the Authorization: Bearer YOUR_API_KEY header, never in a URL. Cookies do not authenticate the API. Create a key with only the scopes the client needs; its secret is shown once.
| Method and path | Scope | Behavior |
|---|---|---|
GET / HEAD /api/v1/codes | codes:read | List codes; use after and the returned next_after for pagination. Lists omit content and destinations. |
POST /api/v1/codes | codes:write | Create one supported editable code. Requires an Idempotency-Key. |
GET / HEAD /api/v1/codes/{id} | codes:read | Read one owned code and its current version. |
PATCH /api/v1/codes/{id} | codes:write | Update supported fields with the current version. An existing code keeps its kind. |
DELETE /api/v1/codes/{id} | codes:delete | Delete with the current version; held codes cannot be deleted through this API. |
GET / HEAD /api/v1/codes/{id}/scans | scans:read | Read the documented aggregate counts, not a raw visitor or answer export. |
Supported editable kinds, subject to their own plan and feature checks: link, call, sms, email, text, wifi, card, app, menu, bio, coupon, event, payment, business. File uploads, galleries and form lifecycle changes keep their dedicated owner controls. There is no answer-body API scope.
Creation uses kind, name, destination and, for a hosted kind, its validated content object. Send a JSON object with Content-Type: application/json; the request body limit is 64 KiB. Do not put credentials, form answers or unrelated personal data into code fields.
Check the result before retrying creation
Use one stable Idempotency-Key for one intended creation and keep the exact request body unchanged. The retained request receipt applies to that key and body, not a different key, a new API credential or an expired receipt. After a timeout, check the known result before repeating work; a missing response does not establish that nothing happened.
Updates and deletes require the returned version. A stale version is a 409: reload and review rather than overwrite it. Validation errors identify rejected fields. A 401 needs valid bearer access, a 403 means the operation is not permitted, and a 429 requires waiting for Retry-After. The current per-key request guard is 60 requests per minute; this is an operational cap, not an added commercial allowance.
For an update, send the complete editable name, destination and content fields. Omitted display settings within content, such as layout, menu language and theme, keep their saved values. Other content fields are replaced; this is not JSON Merge Patch.
Choose the event and destination
Supported source events: scan.created, form.response.created. Messages contain a stable event ID, type, occurrence time and references: code_id, response_id and synthetic. A test uses webhook.test with null resource references. No form-answer body, question text, code destination, account email or raw visitor details are sent. Reference IDs and times are still metadata.
Save an HTTPS destination you control, starting disabled. Check the event selection and data, then explicitly test or enable it. Saving is not a network test. A synthetic test is a deliberate outgoing request; it does not prove a provider completed a workflow.
Verify before acting
The receiver gets Ovbq-Event-Id, Ovbq-Timestamp and Ovbq-Signature. The signature is v1= plus the hex HMAC-SHA256 of timestamp + "." + exact JSON body, using the signing secret. Verify the original bytes with a constant-time comparison, check freshness against your clock and deduplicate event IDs before business actions. Retries have the same event ID and a new signing timestamp.
Keep the signing secret privately. If it is lost or compromised, delete the old webhook, create a new one and update the receiver. Revoking an API key does not disable a separately configured webhook.
Check delivery and retries
The queue is bounded and best effort. Delivery may be delayed, duplicated, exhausted or refused; order and exactly-once processing are not promised. Review sanitized attempt history in your account. An acknowledged HTTP response means transport acknowledgement, not completed remote work.
Disable cancels queued work; delete removes its configuration and retained history. Requests already authorized may still arrive. Tool access and plan limits apply at delivery. A receiver must tolerate retries and reconcile its own business state.
Customer-operated Zapier recipes
This method uses your own Webhooks by Zapier workflow. It is not an ovbq app listing, OAuth connection or Connected status. The outside service's plan, permissions and task limits apply. This reference does not certify an end-to-end provider run.
Use an authorized API action
- Choose one supported owner operation above and a small fictional input.
- Configure an HTTP action in your workflow with the correct method, JSON fields and bearer header. Store the key privately in that service; never put it in a query string.
- For creation, preserve the intended operation's Idempotency-Key and body across retries. Read the returned code ID and link before enabling repeated runs.
Receive a reference event
- Choose the workflow's HTTPS receiving destination and supported event.
- Ensure the request signature, timestamp and event ID are checked before any business action. Use a receiver you control in front of a workflow that cannot perform those checks.
- Queue a deliberate synthetic test and inspect both delivery history and the outside workflow's result. A transport acknowledgement alone is not that result.
Review ongoing access
Owners manage these credentials separately from teammate membership. Remove access you no longer need using the relevant controls in your account. Local revocation does not delete logs, workflow history, spreadsheets or other copies already stored elsewhere.
Bulk creation from CSV is a separate owner workflow.