Events are emitted when certain actions occur on SEEK.
For example, an event may be emitted when:
- A posted job ad has gone live on the SEEK job board
- A candidate has applied for a job ad
- Pushed into your software via webhooks
- Pulled from your software via polling the GraphQL
eventsquery
- CandidateApplicationCreatedEventThese events are emitted when a candidate submits an application for a position.Consuming these events will allow you to retrieve applications submitted using SEEK’s Apply Form; see Optimised Apply for more information.
It is essential that you consume these events for Optimised Apply integrations. Failure to consume these events will mean:
- Hirers will be unable to view job applications via your platform. This wrongs hirers since they will not receive the full value of the advertisement they paid for.
- Candidates will not have their application delivered to the hirer. This wrongs candidates since they miss out on the value that SEEK offers them.
- CandidateProfilePurchasedEventThese events are emitted when a candidate profile is purchased in Talent Search .It is essential to consume these events if you wish to import purchased candidate profiles into your recruitment software.
- HirerRelationshipChangedEventThese events are emitted whenever a relationship between your platform and a hirer is added or removed.The hirer relationships in your software should be kept in sync with SEEK using these events.
- PositionProfilePostedEventThese events are emitted when a job ad is posted.An advertisement’s status in your software should be kept in sync with SEEK using these events.
- PositionProfileClosedEventThese events are emitted when a job ad is closed.An advertisement’s status in your software should be kept in sync with SEEK using these events.
- EfficiencyWith webhooks, you are only notified when an event actually occurs. You can place incoming events onto a queue, and leverage autoscaling and event-driven services to adjust to load.With polling, you need to query our GraphQL endpoint for new events on an interval. This leads to a tradeoff between latency and cost: polling infrequently means that your software will be slower to react to events, while polling too frequently wastes compute resources.
- ScalabilityWith webhooks, you can distribute incoming events across multiple servers and process them in any order.With polling, you need to keep track of pagination cursors and retrieve pages in order. This makes it difficult to distribute your workload across multiple servers.
- SimplicityWith webhooks, you can have a stateless service that simply processes the events that it receives. SEEK takes care of delivering the events to your endpoint; if your service is unreachable or returns an error, SEEK automatically re-queues the events for later.Webhooks also provide a mechanism for SEEK to resend historical events to you on request. This enables disaster recovery without adding any complexity to your integration.With polling, you need to manage state and the complexity of pagination. It can be easy to accidentally skip events while paging through results, and you will probably need to build the capability to retrieve and reprocess historical events for disaster recovery.