How Much Engineering Effort to Integrate Autonomous Tax Agents via API

What does integrating a tax API into an autonomous agent actually require?

Five steps. The first two are the whole integration for a buyer; sellers add the third.

1. Get credentials. Sign up for a free API key, pay per call with x402, or start in demo mode with no key at all. The three options are compared in the table below.
2. Send one request. POST /api/v1/calculate with three required fields (amount, buyer_state, counterparty_id) and a key in a header. Read total_tax from the response.
3. If you sell, configure nexus once. POST /api/v1/nexus with the states where you have a collection obligation. Until you do, seller calls return $0 sales tax with a NEXUS_NOT_CONFIGURED advisory. That $0 is a default, not a finding that nothing is owed, and the advisory says so.
4. Add the optional fields that change the answer. buyer_zip adds city, county and district rates on top of the state rate. work_type tells the engine what kind of work was bought, which decides how each state classifies it.
5. Decide what happens next. Add the tax to an invoice, reserve it in a budget, or record it. Calls made with an API key are recorded to your transaction history (GET /api/v1/transactions) without a second request.

The one default that catches new integrations: role

role is optional and defaults to "seller". transaction_type is optional and defaults to "saas". Both defaults are reasonable for a seller of software and wrong for almost anyone else.

If your agent is buying, send "role": "buyer". A buyer call computes use tax and needs no nexus configuration. A buyer that omits the field is treated as a seller with no nexus, gets $0 back, and has integrated successfully against the wrong question. Send transaction_type whenever the purchase is not SaaS, for example compute, data_purchase or api_access.

A seller's nexus setup is a single call, made once rather than per transaction:

curl -X POST https://agenttax.io/api/v1/nexus \
  -H "X-API-Key: $AGENTTAX_KEY" \
  -H "Content-Type: application/json" \
  -d '{"nexus": {"TX": {"hasNexus": true, "reason": "Economic nexus"}}}'

A minimal request and what comes back

An agent buying $500 of compute from a seller that does not collect, delivered to Austin, Texas:

const res = await fetch("https://agenttax.io/api/v1/calculate", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-API-Key": process.env.AGENTTAX_KEY
  },
  body: JSON.stringify({
    role: "buyer",
    amount: 500,
    buyer_state: "TX",
    buyer_zip: "78701",
    transaction_type: "compute",
    work_type: "compute",
    is_b2b: true,
    counterparty_id: "seller-agent-123"
  })
});
const { total_tax } = await res.json();

The engine's answer to exactly that request (abridged):

{
  "success": true,
  "engine_version": "1.5",
  "role": "buyer",
  "amount": 500,
  "buyer_state": "TX",
  "buyer_zip": "78701",
  "transaction_type": "compute",
  "work_type": "compute",
  "is_b2b": true,
  "jurisdiction": "Austin, TX",
  "combined_rate": 0.0825,
  "classification_basis": "data_processing",
  "sales_tax": null,
  "use_tax": {
    "state_rate": 0.0625,
    "local_rate": 0.02,
    "amount": 33,
    "gross_amount": 500,
    "taxable_amount": 400,
    "taxable_percentage": 0.8,
    "reason": "Seller did not collect. Austin, TX 8.25% combined rate (6.25% state + 2.00% Austin) applied to 80% of Compute/Processing ($400.00 of $500.00)."
  },
  "total_tax": 33,
  "advisories": []
}

Produced by the AgentTax tax engine on the inputs above, and re-checked against it on every build so the two cannot drift apart. The live endpoint also returns a statutory note, a 1099 tracking block, and the full audit_trail listing each rule applied; they are left out here to keep the block readable.

Texas taxes 80 percent of the price of this kind of service, so taxable_amount is $400 and the 8.25 percent Austin rate produces $33. That is the kind of rule an integration does not have to know about: the agent sends a price and a location and reads one number back, with the reason written out next to it.

Where the engineering effort actually goes

Writing the call is the small part. The time goes into three decisions no API can make for you.

• Which side of each transaction your agent is on. An agent that both buys and sells needs to set role per call, not once in a config file.
• What kind of work was bought. The same dollar amount lands differently as compute, research, content, consulting or trading. A wrong work_type produces a plausible, wrong answer rather than an error, so it deserves a test of its own.
• Where the call sits in your flow. A calculation before every purchase is on the critical path. We measured 12 consecutive calls on 2026-09-22: median 164 ms, 90th percentile 228 ms, slowest 476 ms, from the client. Plan for the tail, not the median. The method is on the vendor comparison page.

Read advisories as well as total_tax. A $0 total can mean the transaction is exempt or that the seller has no collection obligation in that state, and those call for different handling. The advisories say which.

Do you need an SDK?

No. The API is plain JSON over HTTPS, and the request above is the whole client. If you prefer a library, both SDKs are published under the same name and were at 0.2.0 on PyPI and npm when this page was written:

pip install agenttax        # PyPI, 0.2.0
npm install agenttax        # npm, 0.2.0

What the integration does not cover

AgentTax does not register you in any state, does not file returns, and has no human review queue.

It answers what is owed on a transaction and why, tracks revenue per state, and warns when a state is approaching the point where registration matters. Registering, filing and paying are separate work, done by you or a filing provider. If that is the part you need, size it separately; this API will not remove it.