Introduction

YunoJuno is an end-to-end contractor engagement platform for businesses that need to discover, engage, contract, and manage independent talent in a controlled way. We sit at the point where talent operations, procurement, compliance, finance, and delivery all meet.

That matters because contractor engagements are rarely just a single action. They involve onboarding the right people, collecting the right information, applying approvals and policy, agreeing commercial terms, and then managing what happens while the work is underway and when it ends.

YunoJuno is designed to make that operating model manageable both in the product and through integrations.

An API-first platform

YunoJuno is API-first.

That does not just mean we expose a few endpoints around the edges of the product. It means the platform is intended to integrate into the systems our clients already rely on: internal workflow tools, procurement systems, vendor management platforms, finance tooling, approval systems, and operational dashboards.

In practice, clients use the API and webhooks to do things such as:

• create and update operational records from their own systems
• drive approval and contracting flows from internal workflow tooling
• surface YunoJuno state inside finance, procurement, or compliance platforms
• react to lifecycle changes as they happen rather than polling for them later

The API is therefore best understood as a way to participate in the same platform model that users interact with in the YunoJuno application.

The core model

At the centre of the platform is the client account. This is the organisation using YunoJuno. Within that account are hirers: the people or systems acting on the client’s behalf. Hirers create and manage the records that drive work forward, and service accounts let those same actions be performed programmatically.

On the other side are contractors. A contractor exists as a person or business on the YunoJuno platform, but each client also has its own relationship with that contractor. That relationship is represented through the client directory and, more specifically, the client contact record. This is why directory lifecycle events and client-contact custom fields matter: they belong to the relationship between a specific client and a specific contractor, not to the contractor globally.

Work itself is then organised through a small number of core business entities.

Projects, spend requisitions, and contracts

A project gives work a business home. It is the organisational container that helps clients group related activity and reporting around a piece of work or budget line.

A spend requisition captures commercial intent before a contract is in place. It is the request to commit spend, often used to bring budget ownership and internal approval into the workflow before a contractor is engaged.

A contract is the formal engagement record. This is the agreement that defines who is being engaged, on what terms, for what dates and rate, and under what operating conditions. Once a contract exists, much of the rest of the platform hangs from it. Contract state is therefore one of the most important things for integrations to understand.

These three entities often appear in sequence. A client identifies a need, anchors it to a project, secures approval for spend, and then creates or offers a contract to the contractor who will do the work.

Control layers around the contract

YunoJuno does not treat a contract as an isolated document. Around the contract are the control layers that determine whether the engagement can move forward cleanly.

Approvals introduce internal sign-off. They answer the organisational question of who needs to agree before spend is committed or before an offer is sent.

Checklists introduce operational readiness. They answer the platform question of what still needs to be true before an action, such as offering or accepting a contract, can proceed.

Together, approvals and checklists are what make the platform useful in real operating environments. They let integrations distinguish between a record merely existing and a record actually being ready for the next step.

During and after the engagement

Once a contract is active, the focus shifts from setup to execution.

Timesheets capture the time worked against a contract. They are the operational record that supports downstream approval, billing, and payment flows. For many clients, timesheets are where finance and delivery teams intersect most directly with the platform.

As engagements progress and end, the platform continues to track the lifecycle of the contract and the surrounding relationship. End dates become known, notice may be served, approvals may be completed, and directory records may continue to evolve even after a specific piece of work has finished.

How to think about integrations

The simplest way to think about a YunoJuno integration is this: your systems are usually not creating isolated records, they are participating in a business process.

That process often starts with a client account and a hirer, moves through directory or project setup, introduces spend and approval controls, formalises the work as a contract, and then continues through time capture and lifecycle updates.

Once that model is clear, the rest of the API becomes much easier to navigate. The individual guides in this section go deeper into the most important parts of that model.