InferOwl includes settings for API keys and webhook subscriptions. These are connection controls. The external system, data flow, supported operations, and implementation responsibilities still need confirmation for your agency.
API-key settings
Owners and managers can view API Keys. Owners can create or revoke keys; managers can review the listed usage and scopes. The creation form asks for a name and selected scopes. A newly created key is shown once, so its owner must store it through the agency's approved secure process.
Before requesting a key, have the technical owner specify the records and operations the connection needs. Confirm that those operations are supported for the agreed integration. Never send a key in an initial support email or include it in a screenshot.
Webhook settings
Webhooks describe where selected event notifications should be sent. Owners and managers can view subscriptions and delivery information. Owners control creation, changes, and deletion. The setup form takes a destination URL and selected events; the signing secret is shown once when the subscription is created.
The receiving system needs a technical owner who can handle and verify incoming messages. Confirm actual event delivery and recovery behavior during technical scoping. Subscription settings and a successful test do not establish that every recruiting event is delivered to the other system.
File imports
Candidate imports provide a separate way to bring a reviewed batch into InferOwl. Use Import candidates in bulk for supported input and review steps. A file import is a batch operation; it does not establish an ongoing synchronization with the source system.
Agree who owns each part
The agency owner approves access and data sharing. A manager describes the workflow and the acceptance checks. The technical owners of InferOwl setup and the external system confirm the connection method, field mapping, permitted writes, monitoring, and recovery process. Agree their responsibilities in the implementation scope.
For each shared field, name the authoritative record, the allowed direction of change, and what should happen when the values conflict. Include a way to identify duplicate records and report unsuccessful or partial updates.
Confirm availability before rollout
Bring the external system name, edition, technical contact, intended records, expected volume, and required direction of data flow to a workflow review. Ask which parts are available in your workspace and which require configuration or additional work. No named ATS connector, automatic two-way synchronization, delivery guarantee, or setup price is established by this reference.
If a connection fails, describe the intended operation, time and timezone, and redacted error. Check the receiving record before repeating a write. Ask the owner to review configuration changes that could affect other workflows.
Describe the intended exchange before choosing a method
Write one example of the record that should move, the event that starts the exchange, and the result the receiving team expects. Identify whether the task is a one-time candidate import, an external application reading permitted information, or a notification that another system must process. These are different implementation questions and should be scoped separately.
For each important field, record its meaning and owner. A source field called status may describe candidate contactability while the destination status describes an application stage. Mapping the names without checking the meaning can create a technically successful but operationally incorrect update.
Agree an acceptance check
Use approved sample data to test the intended operation. Confirm the receiving record, field values, direction of change, and behavior when required information is absent. Ask the technical owners to explain how an unsuccessful or partial operation will be identified and who will investigate it.
Include a duplicate-handling example and a conflicting-value example in the review. Do not assume that repeating a request is safe or that the newest timestamp always identifies the authoritative value. Confirm the actual behavior for the agreed connection before a recruiter relies on it in live work.
Prepare for changes after setup
Assign someone to review changes in the external system, access scopes, field definitions, and receiving destination. A connection can require further review when the agency changes its workflow, even if the settings have not visibly changed. Keep approved configuration references and operational contacts available through the agency's private process.
For a support request, state which exchange failed and whether any records changed before the error. Provide a redacted example through the agreed channel when needed. Never include an API key or webhook signing secret in the initial report. Use the integration-support help article to organize the request and the glossary for mapping, webhook, and system-of-record terminology.