Connect RetailHawk without blurring system boundaries.
RetailHawk can run fieldwork while a configured external questionnaire provider or adjacent business system remains in place. The integration is scoped to the programme, tenant and data flow rather than advertised as universal compatibility with every third party.
External questionnaire handoff with independently verified completion.
1. Provider configuration
An agency-level external-provider registration is configured and versioned for the programme. Provider configuration is tenant-scoped and can be made unavailable without changing historical visit evidence.
2. Shopper handoff
A shopper assignment creates an external-completion session and opens the configured questionnaire destination. Opening the destination is a handoff event — it is not completion evidence.
3. Authenticated completion
A configured provider can send an authenticated completion callback. RetailHawk validates the provider context and correlates the event to the external-completion session.
4. Idempotent evidence
Duplicate or conflicting callback events are handled explicitly. Verified completion remains separate from QA approval, client release, fee entitlement and payment.
Keep assignment, handoff and proof as different states.
asg_demo_42
ext_demo_71
The identifiers above are synthetic. Provider secrets, signing material and production endpoints are never published in marketing documentation.
Use the right interface for the data flow.
Tenant-scoped APIs
RetailHawk uses authenticated, tenant-scoped APIs for application workflows. Where a customer needs API integration, the required resources, permissions and data contract are agreed for that integration. This page does not represent every internal endpoint as an unrestricted public API.
Provider callbacks
The current external-questionnaire pattern includes an authenticated provider completion callback. That is a specific inbound integration contract; it is not a claim that every provider or every arbitrary webhook event works without configuration and testing.
Outbound events
If an adjacent system needs outbound webhooks or other event delivery, define the event, permitted fields, authentication, retry/idempotency behaviour and owning system during technical discovery. Do not assume a generic public webhook catalogue where one has not been agreed.
Manual exception
Where a provider callback is unavailable, an authorised reviewer can use the controlled attestation path defined by the product. Manual attestation is recorded as a different evidence path; it does not pretend an external callback occurred.
Integrate the minimum data needed for the job.
Tenant isolation
Provider registrations and application access remain scoped to the owning agency. An integration does not gain authority to enumerate another tenant.
Secrets stay out of public/programme data
Authentication material is handled as integration configuration, not exposed in customer-visible programme records or examples.
Versioned context
Published programme work keeps the provider/version context it was issued with, so a later configuration change does not silently redefine historical work.
Failure is explicit
An unavailable provider or invalid callback is surfaced as an integration problem. A failed handoff or unauthenticated event is not silently converted into successful completion.
Keep an existing questionnaire system while moving the operating workflow.
A migration does not have to replace every connected system on day one. A bounded programme can move recruitment, allocation, fieldwork tracking and QA into RetailHawk while a configured external questionnaire remains in place, provided the rights, data flow and completion signal are agreed and tested.
What we need before calling an integration supported.
System and owner
Provider/system name, technical owner, contractual/API rights and the business workflow it supports.
Events and identifiers
Trigger, correlation identifiers, source of truth, idempotency key and expected state transitions.
Authentication and failure
Authentication/signature method, credential ownership, retries, timeout behaviour, replay protection and exception ownership.
Data and retention
Permitted fields, controller/processor roles, sensitive-data boundary, retention and audit requirements.