Real questions from teams
‍running connected recruiting.

Managed recruiting connectivity means a provider builds, operates and monitors the integrations between recruiting systems for you, not just the initial connection. The ATS stays the system of record. The connectivity layer moves jobs outward and applications back, and owns retries, mapping changes and connector updates as an ongoing service.

The distinction that matters is ownership over time. Wiring two systems together is a one-off project; keeping that wiring alive through API changes, new field requirements and platform policy updates is an operating task. Managed connectivity puts that second part in the contract rather than on your roadmap.

An ATS integration is a connection between an applicant tracking system and another tool, such as a job board or a social recruiting channel, that lets them exchange jobs and candidate data automatically. Without one, recruiters copy postings out and applications back in by hand.

In practice three things decide whether an integration holds up: field mapping between systems that model candidates differently, error handling when one side is unavailable, and who maintains the connector when a provider changes its API. Most integrations fail on the third point, not the first.

A unified API abstracts many systems behind one generic schema, but you still build, monitor and fix the integration yourself. Managed connectivity keeps recruiting-specific mappings per system and includes the operating work: monitoring, retries, recovery, and connector updates when a provider changes its API.

The trade-off is abstraction versus fidelity. A generic schema is fast to adopt but flattens the details that matter in recruiting: hiring stages, screening questions, board-specific publishing rules. Per-system mappings keep those details and shift the maintenance cost to the provider.

General iPaaS tools move events between apps but carry no recruiting semantics. They do not know what a hiring stage, a screening question or a duplicate candidate is, and they leave mapping, retries and board-specific policy rules to you. Recruiting-native connectivity ships those defaults verified per system.

The gap shows up in the edge cases, not the happy path. A generic workflow can post a job; it cannot tell you that a board rejected it for a missing salary range, that a candidate already exists in the target ATS, or that a screening answer no longer matches the question it belongs to.

Multiposting means publishing one job ad to many job boards at once instead of entering it on each platform separately. In practice it requires per-board field mapping, because every board expects different data. That is why multiposting is normally built on an integration layer rather than a form.

The complexity is not the posting itself but everything around it: each board has its own required fields, character limits, category taxonomies and publishing rules, and each returns applications in its own shape. Those differences have to be resolved somewhere, either by your team or by the connector.

Yes. For every ATS Kini already supports, the connector and its default field mapping exist, and anything specific to a customer's setup is mapped by the Kini team. What still needs a person is access: someone at the company has to authorise the connection to their ATS, usually through a magic link.

Where a developer does become useful is the other direction: when you want to push jobs or pull application data into your own product. That runs through the public API, but it is optional, because the managed path works entirely through the app.

Building one connector is a project; keeping twenty running is a team. The recurring cost sits in maintenance: API changes, edge cases, monitoring and per-customer credential handling. In-house makes sense when integrations are your product. Buying makes sense when they are a prerequisite for selling yours.

A useful test: count how many of your customers would notice within an hour if a connector stopped delivering applications. If the answer is most of them, you are running an operations function, not a project, and it needs staffing, on-call and monitoring regardless of who wrote the code.

They solve a different problem well: broad HR coverage behind one schema, aimed at product teams who build and run the integration themselves. Kini is recruiting-specific and includes the operation: per-customer onboarding, monitoring, retries and connector maintenance. Which fits depends on whether you want an API or an operator.

There is also a coverage difference. Unified APIs concentrate on HR and payroll systems; recruiting workflows additionally need job boards, social recruiting channels and screening tools, plus the publishing rules that go with them. If your use case ends at the ATS, a unified API may well be enough.

Onboarding starts with a call about your use case, volumes and the systems your customers use. Then we run the first magic-link onboarding with a pilot end-customer, check it with a real test application and go live together. The DPA is signed before go-live.

The pilot exists to surface the specifics of your setup before they multiply: which systems your customers actually run, which fields matter to you, and how you want applications to arrive. Everything learned there becomes the default for every customer you onboard afterwards.

For an ATS Kini already supports, the connection itself is set up in minutes once we have the credentials. What usually takes longer is getting them: some ATS vendors need a step on their side first, such as issuing an API key or a certificate, or allowlisting Kini. Kini then checks the setup with a test application and activates the integration.

If your first customer runs a system Kini has not connected yet, the timeline depends on building that connector, and we say so in the first call rather than afterwards.

No. With magic-link onboarding your end-customer enters their own ATS credentials through a link you generate, so you never see them. For some systems the customer's ATS admin or vendor has to create the credentials first, for example an API key or a certificate. If you already hold credentials, you can enter them yourself, alone or together with the customer during a call.

This matters commercially, not just technically. Asking a customer to hand over admin credentials is a conversation that stalls deals; asking them to click a link and authorise a connection in their own system usually does not. It also keeps your company out of scope for their credential policy.

A magic link is a link you send to an end-customer so they can connect their own ATS. Credentials go directly to Kini and never touch your systems. Setup guides with screenshots exist for many ATS, and we join onboarding calls when you want us there.

The alternative path stays open: if you already hold a customer's credentials, you enter them yourself through the same wizard, alone or together with the customer on a call. Both routes end in the same place: a connected company you can then manage from your workspace.

Less than most teams expect. Your end-customer connects their own ATS through the magic link, so no engineering work happens there. On your side one technical contact for the API key and webhook endpoint is enough. Kini has setup guides for many ATS and joins onboarding calls on request.

The heavier lift is usually commercial rather than technical: deciding which customers to onboard first, and how you want to present the integration to them. That is what the discovery call and the pilot are for.

Mapping and data enrichment happen on the Kini side, so you integrate in whatever format already suits you. We map into the target format, enrich data and handle screening questions. If a partner system needs its own connector, we can build it rather than asking you to adapt.

That principle also covers how you deliver data: API, XML feed or JSON feed all work. The point is that the adaptation happens once, in the connector, instead of repeatedly in every customer project.

Both. The onboarding wizard gives you two paths: enter credentials yourself, alone or with the customer on a call, or send a magic link and let the customer do it. The partnership starts guided with a call; after that, you invite customers yourself, and Kini checks and activates each new connection.

The design goal is that the guided part happens once. After the pilot, adding a customer should be something an account manager does without involving engineering on either side.

Sometimes. For some systems, the ATS vendor or the customer's ATS admin has to complete a step first, for example issuing API credentials, setting up a certificate or allowlisting Kini. Kini prepares these requests for you, and the customer then connects through the magic link.

Send a test application to a live job, using a unique name and email address so the ATS does not reject it as a duplicate. Kini checks the result in the logs. If the test shows a setup issue, such as a wrong base URL, Kini corrects it and syncs the candidate again.

Open the customer in the Partner App, generate a new magic link and send it to the customer. They enter the new credentials, and the connection continues. For SAP SuccessFactors, Kini issues a new certificate on request.

Through Kini. Jobs are read from Personio, mapped to StepStone's required fields and published through Kini Shop.

The work sits in the translation. Personio models a job one way, StepStone expects another, and neither side adjusts for the other. A maintained connector absorbs that difference, including when Personio changes its API.

Indeed sends each application to Kini, where it is converted into the format the ATS expects and written in as a candidate. What arrives is what Indeed provides: contact details, the CV, an optional cover letter and answers to supported screening questions. Every record carries a sync status, so a failed hand-off is visible rather than silently lost.

Normalisation is the part that is easy to underestimate. Screening questions differ per job, attachments arrive in different shapes, and the target ATS validates strictly. Getting that wrong does not produce an error message to the recruiter. It produces a candidate who never appears.

Yes. Jobs are read from the ATS once and distributed to the boards you book, each with its own field requirements handled. Through Kini Shop you can book an ad on any of 1,500+ job boards, or run several jobs as a campaign on platforms such as Indeed.

Publishing is only half of it. Boards also report back (published, publish failed, expired), and those states have to reach your system so nobody assumes an ad is live when it is not. Kini pushes them as booking status events.

Kini Core connects 65+ ATS, plus job boards, social recruiting and screening tools. Supported ATS include Personio, softgarden, d.vinci, SAP SuccessFactors, onlyfy, rexx, HR WORKS, zvoove, coveto and GuideCom. The integrations page carries the current list.

Coverage is curated rather than exhaustive on purpose. Each connector comes with a default mapping for its system, which is what makes it work without configuration, and what makes adding one a real piece of work rather than a checkbox.

Three options. We build a custom connector to your system with the mapping on our side; you connect through the Kini API using our public docs; or you deliver jobs as an XML or JSON feed. You can also request a missing system directly from the picker in the app.

The underlying principle is that Kini adapts to your setup rather than requiring a specific format from you. That is a deliberate difference to API-only providers, where the integration has to be built the way the provider expects.

Through Kini Shop. StepStone, Indeed, XING, meinestadt and many regional boards can be booked there, and each board's required fields and publishing rules are taken care of. Overall, Kini Shop gives access to 1,500+ job boards.

DACH boards are where generic international tooling tends to break down: different taxonomies, different mandatory fields, and publishing rules that change without much notice. Handling those is a regional specialisation, not a translation layer.

Yes. The Kini API is public and documented at docs.getkini.com. Authentication uses Bearer API keys that you create with an expiry and revoke yourself in the Partner App. Jobs are pushed with POST /jobs, and applications are submitted and tracked through the same API.

Requests are scoped per connected company through a Company-Id header, so a single key can serve all of your customers while keeping their data separate. Rate limits also apply per company rather than per partner.

By default, jobs move outward from the ATS to your channels, and applications move back into the customer's ATS. For some ATS, Kini can also read applications from the ATS and pass them on to other systems.

Which direction matters depends on the partner: a job board consumes jobs and returns applications, while an ATS vendor brings its jobs to channels and receives applications back.

Each connector comes with a default mapping for that system's fields, so most setups work without configuration. Where a customer's setup differs, the Kini team adjusts the mapping. Mapping and enrichment stay on the Kini side rather than becoming your problem.

Enum and status mapping is usually the hardest part, because two ATS rarely model a hiring process the same way. Default mappings per connector exist so that this is solved once rather than per customer.

That depends on the ATS. Kini passes a source with each application, for example the name of the job board, and each system handles it differently. Some ATS only accept sources that already exist there, so these need to be set up before go-live.

By default, Indeed delivers contact details, the CV and an optional cover letter, and Kini passes them on to the ATS. Further documents can be requested as part of the application. Address data is not part of Indeed's standard data; if you need it, a required screening question is the reliable way to collect it.

Both, depending on direction. By default, Kini pulls jobs from a connected ATS once an hour, and career-page crawling works the same way. The interval is set per company and can be shortened on request. Applications are sent to the ATS as they come in, and events (job created, updated or archived, application sync status, booking status) are pushed to your endpoint by webhook.

The split is deliberate. Polling an ATS constantly would hit rate limits for no benefit, while applications and status changes are time-critical and therefore pushed. If you need a job change faster than the schedule, the Job Updates webhook tells you the moment it happens.

Four ways. You push them through the API with POST /jobs, Kini pulls them from the connected ATS on a schedule, Kini crawls the company's career page, or a user creates them by hand in the Kini App.

Career-page crawling matters more than it sounds: it covers companies whose ATS has no usable API, which in the DACH mid-market is a meaningful share. From your side those jobs work like API-sourced ones.

Outbound: jobs, including their application form fields and job-specific screening questions. Inbound: applications with answers and attachments, delivered into the customer's ATS. Every application also carries a sync status.

The screening questions are the part worth planning for. They are defined per job and can change after publication, so an application form that caches them will eventually submit answers to questions that no longer exist.

The API is not idempotent: every POST creates a record. So send your own partner_application_id with each submission and check before retrying. When the customer's ATS rejects an already-known candidate, Kini marks the application EXPECTED_FAILURE with failure_error DuplicateApplicationError rather than treating it as a real error.

That distinction keeps your monitoring honest. A duplicate is an expected outcome, not a broken integration, and mixing the two is how teams end up ignoring their error dashboards. Always read failure_error rather than the status alone, because EXPECTED_FAILURE also covers cases like a job that is no longer published.

It is managed. Connectors come with a default mapping per system, so most setups need no changes, and where a customer's setup differs, the Kini team adjusts the mapping for you.

That is the intended pattern: the defaults make customisation the exception, and when it is needed, it happens on the Kini side instead of in your code.

Kini owns that. When a provider makes breaking API changes, Kini updates the connector so your side of the integration does not have to change. Rate limits and policy quirks per connector are handled in the background, so neither you nor your end-customers have to track them.

This is the recurring cost that in-house integrations underestimate. Providers change fields, deprecate endpoints and tighten validation on their own schedule, and every one of those changes is a small outage for someone unless a maintainer catches it first.

Yes, per record. Every application carries its latest sync status (SUCCESS, SUCCESS_FALLBACK, FAILURE, EXPECTED_FAILURE or NOTSENT) plus a failure_error for diagnostics. In the app you get per-customer sync KPIs and a status per record; programmatically you poll GET /applications or subscribe to the webhook.

When a customer asks what happened to a specific candidate, the answer is a status and a reason rather than a log search. Kini keeps the latest status per application, not a full history of every attempt.

Make changes in the ATS. It is the source system, and every update sends the complete ad again, so edits made directly on the board are overwritten. If the ATS refreshes a job automatically and gives it a new ID, the job can drop out of a running campaign that is linked to that ID.

Worth asking before signing. With in-house builds and unified APIs the answer is usually you. With a managed layer it should be contractual: monitoring, retries and connector updates on the provider's side, plus a per-record status you can verify rather than a promise you have to trust.

The practical test is what happens at 9am on a Monday when a board changed a required field over the weekend. Either someone is already fixing it, or your support team finds out from a customer.

Monitoring and retries are part of the product, not an add-on. Failed syncs are retried automatically and keep an explicit status instead of being dropped silently. When retries do not fix it, a person on the Kini team looks at it.

The design principle is that nothing disappears quietly. A record that could not be delivered keeps a visible state and a reason, which is what makes recovery a decision rather than an investigation.

Every application carries a visible status. In the app you see per-record pills such as Notsent and Failure, sync icons per customer and a dashboard with sync KPIs. Programmatically the same information arrives through the Application Sync Status webhook or by polling GET /applications.

The status is per record rather than per integration on purpose. An integration that is “up” while individual candidates silently fail is the failure mode that costs partners their customers.

Yes, a manual re-sync trigger per customer is built into the app. For automated handling, the Application Sync Status webhook delivers the failure_error so your system can react. One caveat: a 400 validation error will fail again unchanged, so fix the payload before resubmitting.

Retries are also worth designing on your side. If a submission times out, check whether the application already exists via its partner_application_id before sending it again, because the API creates a new record on every POST.

Through webhooks. Job Updates fire on create, update and archive. Application Sync Status reports delivery into the ATS. Job Booking Status covers BOOKED, PROCESSING, PUBLISHED, PUBLISH_FAILED, UNPUBLISHED and EXPIRED with a transaction_id for tracing. Send your endpoint to tech@getkini.com to enable them.

Job event notifications are the ones partners tend to value most: you learn when an end-customer publishes, updates or closes a job without polling every ATS on a timer.

Yes: 60 requests per minute per connected company, identified by the company_id on the request. The limit applies to each of your customers separately, so ten connected companies get ten separate budgets. A few endpoints differ; those are noted in the API reference.

Per-company limits mean your throughput scales with your customer base rather than hitting a single shared ceiling. It also means a bulk operation for one customer cannot be spread across the others.

Each connected company is addressed by its own company_id, and the Partner App shows a company switcher plus a customer table with lifecycle states such as Active, Invited and Requested. Sync icons in that list show at a glance whether each customer's connection is healthy.

For agencies and platforms managing dozens of end-customers, that list is the actual daily interface: it answers who is live, who was invited but has not connected, and where something needs attention.

Every delivery attempt sends its own webhook event, so a failure followed by a successful retry produces two events. Always use the latest event for an application and overwrite the previous status.

Breaking changes are announced to partners in advance, so you have time to adapt your integration. All other changes, such as new endpoints, fields or webhook events, are documented in the API documentation.

It can be, but compliance comes from the setup, not from the connection itself. Look for EU hosting, a data processing agreement (DPA) signed before go-live, a defined retention period and clear rules on who deletes what. Kini is hosted in Frankfurt and deletes or anonymizes personal applicant data 180 days after an application is created.

The retention question is the one most often skipped. An integration that keeps candidate records indefinitely quietly turns every partner into a long-term data controller for data they no longer need. That is exactly what data minimisation is meant to prevent.

Applications carry detailed personal data, and every transfer outside the EU adds a legal justification your procurement team has to defend. EU hosting removes that step. Kini's platform runs in Frankfurt, Germany, and no third-country transfer is part of the standard setup.

For DACH buyers this is frequently a hard filter rather than a preference: it decides whether a vendor reaches the shortlist at all, before anyone looks at features.

Kini's platform and database run on Google Cloud in Frankfurt, Germany, and data is encrypted in transit and at rest. Kini deletes or anonymizes personal applicant data 180 days after an application is created.

Retention depends on the field: reporting fields such as job, channel, status and timestamps stay available, while personal applicant data is removed on a fixed schedule.

Yes. Kini operates under GDPR and provides an AVV/DPA template before sign-off, so your legal review can start before the contract closes. Security and data-handling questions are meant to be answerable without a sales call.

Getting the DPA out early is deliberate: in most partner deals legal review runs in parallel with the technical pilot, and a template that arrives late becomes the thing that delays go-live.

Applications are automatically anonymised 180 days after they were created. Personal fields (candidate details, attachments, notes, social links, screening answers, custom fields) are then removed from API responses entirely. Reporting fields such as job, channel, status and timestamps remain available indefinitely.

Two practical consequences: sync any candidate data you need into your own system within the window, and treat the personal fields as optional in your integration, because after 180 days the keys are absent rather than empty. Filters on email also stop matching anonymised records.

Credentials are managed per end-customer inside Kini Core, stored as encrypted secrets and never returned by the API. With magic-link onboarding the customer enters them directly, so they never pass through your systems. Your API keys are separate: you create them with an expiry and revoke them yourself in the Partner App.

Keeping the two apart is what lets a partner offboard a customer without rotating anything on their own side, and revoke their own key without touching customer connections.

No. Customer data is not used to train AI models.

It depends on the model. Built in-house, the cost is engineering time plus ongoing maintenance per connector. With a managed provider it is usually a recurring fee tied to one value metric. At Kini that is the number of integrated end-customers, with no setup fee. Current prices are on the pricing page.

The number that surprises teams is the second year, not the first. Building is a one-off; maintaining a growing set of connectors is a permanent line item, and it scales with customers rather than with effort saved.

None of those. Kini Core is billed per integrated end-customer, a single axis, and the price per customer drops in higher tiers. Kini Shop has a monthly fee plus a margin split on shop revenue. The tiers (Lite, Basic, Grow and Enterprise) and their prices are on the pricing page.

A single value metric is a deliberate choice: it means your cost moves with the value you get rather than with API calls or seats, and it stays predictable as usage inside each customer grows.

No. We work in close partnerships rather than charging for onboarding. The minimum term is twelve months, and it comes with a 30-day money-back guarantee: cancel within 30 days, no reason needed, no charge.

Removing the setup fee shifts the risk to us on purpose. It also removes the negotiation that usually delays a first pilot by weeks.

A single axis. For Kini Core it is the number of integrated end-customers, not seats or API calls. Tiers are tied to minimum volumes and discounts apply at integration level, so the price per customer drops as you grow.

Billing starts when an integration for a customer is created through the onboarding app.

Yes. You can request additional integrations or move to a higher bundle during the term, and we issue a revised offer based on the remaining term and what you have already paid. Reductions are possible with three months' notice to month-end.

Core and Shop stay separate products throughout: you can add one later without restructuring the other, and neither is an add-on to the other.

Instead of a trial we offer a 30-day money-back guarantee: cancel within the first 30 days without giving a reason and without paying. A connectivity layer only proves itself against real customers and real data, which a limited trial account cannot provide.

That is also why the pilot end-customer is part of onboarding rather than an optional extra: the first real connection is the trial.

Twelve months. It is paired with the 30-day money-back guarantee, so the real commitment only starts after you have seen the integration run with your own customers. After the initial term the contract continues indefinitely with three months' notice.

There is no setup fee on top, which means the twelve months are the entire commitment rather than the second half of one.

Monitoring, retries and connector maintenance are part of the product rather than a support tier. Questions go to the Kini team at tech@getkini.com, and depending on your plan you also get a shared Slack channel with Kini engineering.

Because connector maintenance is included, many issues are handled on the Kini side without a ticket from you.

The same single axis applies: you pay per integrated end-customer, so cost scales with the client base you actually connect. Tier discounts apply at integration level, which means the per-client price falls as your portfolio grows.

Agencies also get the parts built for managing many clients at once: a company switcher, per-customer sync status, and separate billing details including VAT ID and cost centre per end customer.

Yes. Kini Shop is open to companies directly and basic usage is free: you only pay for the products you book. Paid tiers add multi-organisation management, custom ATS connections, multiple cost centres and negotiated multiposting prices.

The free tier is a real starting point rather than a demo: you can connect your ATS, publish jobs and receive applications without a contract discussion.

Kini Shop gives you access to 1,500+ job boards, and you book each ad where you want it to run. You can also run several jobs as a campaign on platforms such as Indeed, with one budget for the campaign.

Booking runs in four steps: choose the product, configure the ad, enter billing details and review. What a posting costs is visible before you commit to it.

Yes, direct integration with your ATS is included. Applications from booked channels are normalised and written back into your ATS, so your system stays the single source of record and nobody copies candidates by hand.

That is the difference to booking each board separately: the ad goes out through many channels, but the applications come back into one place in a consistent shape.

Basic shop usage is free; you pay per booked product. Paid tiers unlock multi-organisation management, custom ATS connections and your own suppliers. The add-ons LinkedIn Chrome Extension and Kini Social Media are billed by users or by candidate volume. Prices are on the pricing page.

Higher tiers exist mainly for companies with several hiring entities or negotiated board rates, not as a gate on the basic workflow.