Menu

Kort antwoord over Pay. en Recruitee

Pay. en Recruitee delen 0 dataobjecten, maar aan één kant ontbreken de schrijf-endpoints; koppelen vraagt hier maatwerk.

Pay. en Recruitee bieden allebei webhooks; synchroniseren kan daarmee realtime.

Score 30 van 100 voor Pay. en Recruitee: reken op 5 tot 10 dagen werk voor een maatwerkkoppeling.

Pay. en Recruitee: bijgewerkt op 2026-09-11 vanuit hun API-documentatie.

Gedeelde dataobjecten
0
Richting mogelijk
0
Webhooks
beide kanten
Koppelbaarheidsscore
30/100
Inspanning
5 tot 10 dagen

Wat Pay. en Recruitee elk apart aanbieden

Geen enkel dataobject komt in beide API's voor met endpoints aan weerszijden. Wel hebben beide pakketten hun eigen objecten, en die bepalen wat een koppeling kan overbruggen. Het getal is het aantal endpoints dat het pakket voor dat object aanbiedt.

Alleen in Pay.

  • Transactie: 33 endpoints
  • Merchant: 30 endpoints
  • Clearing: 19 endpoints
  • Account: 17 endpoints
  • Authenticatietoken: 13 endpoints
  • Service: 13 endpoints
  • Terminal: 10 endpoints
  • Betaalmethode: 9 endpoints
  • Authorisatiegroep: 8 endpoints
  • Incasso: 8 endpoints
  • Kaartbetaling: 7 endpoints
  • Licentie: 7 endpoints

Alleen in Recruitee

  • Kandidaat: 9 endpoints
  • Vacature: 8 endpoints
  • Integratie: 4 endpoints

Elk object aan de ene kant zonder tegenhanger aan de andere vraagt een eigen vertaalslag: je bepaalt zelf welk veld waar terechtkomt.

Pay. en Recruitee in de praktijk

Tweeëntwintig objecten bestaan maar aan één kant en gedeelde dataobjecten zijn er niet. Pay. verwerkt betalingen en Recruitee begeleidt sollicitaties, en die twee raken elkaar nergens.

De enige denkbare aanleiding is een betaald assessment of een cursus die een kandidaat zelf afrekent, en dat regel je via het systeem dat die dienst aanbiedt en niet tussen deze twee. Houd kandidaatgegevens gescheiden van betaalsystemen: de mensen die betalingen beheren hoeven geen sollicitanten te zien. Recruitee stuurt meldingen maar heeft geen sandbox, Pay. kan statuswijzigingen pushen en heeft er wel een.

Technische aandachtspunten bij Pay. en Recruitee

  • Pay. werkt met API-key of Bearer-token, Recruitee met Bearer-token.
  • Rate limits: Pay. Niet gespecificeerd; Recruitee Niet gespecificeerd. Throttle op de strengste van de twee.
  • Alleen Pay. heeft een sandbox; de andere kant test je op een aparte administratie.
  • Stijl en formaat: Pay. (REST, JSON) tegenover Recruitee (REST, JSON).
  • Versiebeheer loopt bij Pay. via url en bij Recruitee via url; leg de versie vast en bewaak deprecaties.

Veelgestelde vragen over Pay. en Recruitee

Welke dataobjecten delen Pay. en Recruitee?

Pay. en Recruitee delen geen dataobjecten met endpoints aan beide kanten; een koppeling vraagt een eigen mapping.

Kan Pay. realtime met Recruitee synchroniseren?

Ja. Pay. en Recruitee sturen allebei webhooks, dus een wijziging kan direct de andere kant op.

Hoeveel werk is een koppeling tussen Pay. en Recruitee?

Met een koppelbaarheidsscore van 30 van 100 komt de koppeling van Pay. en Recruitee uit op 5 tot 10 dagen voor één of twee dataobjecten. Meer objecten, transformaties of goedkeuringsstappen tellen daarbovenop.

Pay. en Recruitee: welke authenticatie is nodig?

Pay. werkt met API-key of Bearer-token, Recruitee met Bearer-token. De koppeling beheert de tokens van beide kanten en vernieuwt ze automatisch.

Kun je een koppeling tussen Pay. en Recruitee testen zonder productiedata?

Deels: Pay. heeft een sandbox, voor Recruitee gebruik je een aparte testadministratie.