The freelancer profile belonging to the account this API token authenticates as, including the owner-only fields (email, whether the profile is listed in the directory). Requires READ_OWN. Use this first to confirm which account and organization the token is acting for - every other tool acts as this identity, and there is no argument anywhere that can aim one at somebody else.

Search the talent directory for listed freelancers - the people available to hire. Requires READ_DIRECTORY. Returns the public half of each profile only; contact details and verification documents are never in this projection. Omit filter entirely to see who is listed at all, then narrow: a search that returns nothing on the first try usually over-constrained city or skills.

One freelancer from the directory by id, as the public projection shows them. Requires READ_DIRECTORY. Ids come from freelance_search_talent - a name is not an id, and there is no lookup by name.

Search open, publicly visible job postings across the whole marketplace - the work available to bid on. Requires READ_DIRECTORY. This is the FIND WORK side; for your own organization's requisitions in any status, including closed and organization-only ones, use freelance_list_org_jobs instead.

Your own organization's job postings, in any status and including ORGANIZATION-visibility ones the public search never returns. Requires READ_OWN. This is the hiring side's list - use it to find the posting id you need before reading its proposals.

One job posting in full by id. Requires READ_DIRECTORY. Re-authorized on the server rather than trusted: your own organization sees any of its postings, everybody else sees PUBLIC ones only, and an ORGANIZATION-visibility posting you have no claim to comes back empty rather than refusing - that is the privacy boundary working, not a broken id.

Publish a job posting to the marketplace under your organization's name. Belongs to the HIRE scope, and requires an organization context on the token - a personal token with no organization has nothing to post as. THIS IS VISIBLE TO REAL PEOPLE THE MOMENT IT LANDS: freelancers see it in search and can bid on it, so confirm the title, the budget and the description with the person you are acting for before calling this, never off your own reasoning. Set visibility: ORGANIZATION to keep it inside your organization while it is being worked on.

The bids this account has placed, and the invitations it has received. Requires READ_OWN. Status INVITED means a client pulled this account into a posting and nobody has bid yet.

Every bid on one of your organization's job postings - the hiring side's applicant list. Requires READ_OWN, and the posting must belong to your organization; asking about somebody else's requisition is refused, not filtered.

Bid on a job posting in this account's name. Belongs to the PROPOSE scope. THIS REACHES A REAL PERSON: the cover letter is read by the client as words this account wrote, so get the person you are acting for to approve the text and the rate before calling - never bid off your own reasoning about a good match. Read the posting with freelance_get_job first: if it carries applicantQuestions every one must be answered here, and if it carries acknowledgments you must send acknowledged: true, or the bid is refused.

Hire a bidder: accepting a proposal MINTS A CONTRACT and returns it. Belongs to the HIRE scope, and the posting must be your organization's. This is a commitment to a person, not a draft - confirm with whoever you are acting for first. It commits no money on its own; funding happens later, per milestone, through freelance_fund_milestone.

Contracts where this account is either the freelancer or the client organization. Requires READ_OWN. Pass filter.role to pick a side: FREELANCER is work this account is doing, CLIENT is work it is paying for. Without it you get both, which is rarely what a question means.

One contract by id, with its milestones and their escrow state. Requires READ_OWN and membership of the contract. READ THIS BEFORE APPROVING ANYTHING: a milestone whose escrowStatus is FUNDED releases real money when approved, and that is the case where freelance_approve_milestone requires acknowledge: true.

Add a milestone to a contract - a named piece of work with an amount and a due date. Client lane: the contract must be your organization's. Belongs to the HIRE scope. Adding one commits no money; it only describes what a later payment would be for.

Hand a milestone in for review, moving it PENDING -> SUBMITTED. Freelancer lane: this account must be the contract's freelancer. It claims the work is done and puts the client on the spot, so do not call it on the freelancer's behalf without their say-so.

MOVES MONEY. Commit a milestone's amount to escrow before the work starts. Requires the SPEND scope, which the server enforces - an agent identity without it is refused with FREELANCE_AGENT_SCOPE_REQUIRED, and the fix is a human granting the scope, not a retry. The money leaves the organization's spendable balance and is HELD: still the organization's, no longer spendable, not yet the freelancer's. No acknowledgement flag is needed because this is reversible - freelance_refund_milestone takes it straight back while the work is unapproved.

MOVES MONEY. Take escrowed money back out of a milestone and return it to the organization's spendable balance, while nothing has been handed over. Requires the SPEND scope, enforced by the server. Reversible - funding again restores it - which is why it carries no acknowledgement flag. It is still a decision about somebody's pay: confirm it before calling.

MOVES MONEY, AND CANNOT BE UNDONE. Approve submitted work, moving the milestone SUBMITTED -> APPROVED -> PAID. On a milestone whose escrowStatus is FUNDED this is the call that RELEASES the escrow: the held money becomes the freelancer's cash-out balance, and nothing in this product can pull it back. Requires the SPEND scope, enforced by the server. ON A FUNDED MILESTONE YOU MUST SEND acknowledge: true, and that flag means one specific thing: the person you are acting for has been told the amount and the payee and has said yes to THIS release. It is not a formality to set by default. Call it without the flag first if you are unsure - the refusal comes back as FREELANCE_ACKNOWLEDGEMENT_REQUIRED and carries the exact amount, currency and payee, which is the sentence to put in front of the person before you re-send with the flag. The flag is per call and never per session: a milestone's amount can change between two calls, so consent to an earlier one is consent to a different number. On a milestone nobody funded, the flag is ignored and this only moves the status.

The account's wallet: money available to hire with (toSpend), earnings available to cash out (toCashOut), money committed to milestones (inEscrow), and recent ledger entries. Requires READ_OWN. A READ - it moves nothing. Check toSpend against a milestone's amount BEFORE calling freelance_fund_milestone: funding more than the wallet covers is refused outright and leaves the milestone unfunded rather than half-funded.

Message threads this account takes part in, with unread counts. Requires READ_OWN. A thread is anchored to a posting, a proposal or a contract - that anchor is how you tell two threads with the same person apart.

One thread and its messages. Requires READ_OWN. NOTE A SIDE EFFECT: reading a conversation MARKS IT READ for this account, which clears the other side's "unread" signal. Do not sweep every thread to summarise an inbox unless the person asked you to - use the unread counts from freelance_list_conversations for that, which change nothing.

Send a message to a real person, under this account's name. Belongs to the MESSAGE scope. NOTHING UNDOES THIS - there is no edit and no delete, and the recipient is notified. Show the person you are acting for the exact wording and get a yes before calling; drafting a message is always fine, sending it is what waits. Address it EITHER with conversationId for an existing thread, OR with exactly one of jobPostingId / proposalId / contractId / freelanceProfileId, which finds or opens the thread anchored to that object.

This account's own notification feed, newest first. Requires READ_OWN. The recipient is taken from the token and can never be passed in. side picks the lane and is effectively required - FIND_WORK is "things happening to my bids", HIRE_TALENT is "things happening to my requisitions" - because the two are different jobs and a merged feed answers neither.