When to use a group
- A printed batch (a thousand table cards, a poster run) where every code should route the same place.
- A campaign you want to flip live, pause, or retire as a unit.
- A staging area for codes you’ll later split into different destinations — start them grouped, then break out the ones that need their own routing.
Inheritance model
When a QR code is in a group and the group has adestination_type (or status) set, the child’s own field can be left blank to inherit the group’s. If the child sets its own, the child wins. This lets you bulk-configure a whole campaign of codes from the group level, and break individual codes out later when they need to diverge.
Inheritance is resolved at scan time, not cached on the child. Update the group and the very next scan on any inheriting child picks up the change.
The same resolution applies to status: child first, then group, then default.
Worked example
Group with a shared destination and an inactive child:destination.type is null on the child, so the scan resolves to the group’s page.
A second child in the same group that overrides:
destination.type is set on the child, so the group is ignored — the scan goes to the chatbot.
CRUD workflow
1
Create the group
POST /qr-groups with a name and (optionally) a shared destination.2
Mint child codes
Codes are minted in the dashboard and tied to the group via
group_id. The v1 API is read/update-only for the QR code resource — new codes come from the dashboard.3
Re-route the whole group
PATCH /qr-groups/{id} and update the destination object. Every inheriting child picks up the change on the next scan.4
Pause or archive
Flip
status on the group to inactive or archived to pause or retire every inheriting child at once.Deleting a group
DELETE /qr-groups/{id} removes the group row. Child codes are not deleted — the database foreign key uses ON DELETE SET NULL, so children have their group_id cleared and stand alone. Their own destinations (if set) take over; inheriting children become unconfigured until you give them their own destination.
URL params and properties on groups
A group also carries its own static URL params and properties (separate tables:qr_group_url_params, qr_group_properties). At scan time they merge with the child’s params — child overrides on key collision.
qr_context reports.
Group properties
GET /qr-groups/{id}/properties lists the group’s properties; PUT /qr-groups/{id}/properties replaces the full set. Properties not in the request body are removed, and an empty properties array clears them all. Keys must be unique within a request (a duplicate returns 422). Both endpoints have the same request and response shape as QR code properties. PUT requires a plan that includes QR properties (402 otherwise).
Attach knowledge
Link the articles and folders that are specific to this group. Visitors who scan it get them on top of the chatbot’s own knowledge, so a question like “how do I turn the TV on?” is answered from this group’s manual, not a guess across every one. Group links apply to every code in the group; you can also send them onPOST /qr-groups. Both arrays are replace-only: send the full desired set every time.
Webhook events
Subscribe and verify signatures per the webhooks guide.

