What you build with it.
The endpoints do distinct jobs. Pick yours.
Your customers' finished tax documents, retrieved by API into your own experience. No redirect, no separate portal.

For customers running cost basis on Taxbit, the endpoints return live tax lots, inventory, and realized and unrealized gains. Your front end shows the data, and the engine keeps them accurate.
The same endpoints feed your internal tools, so a support agent sees the customer's forms and tax data without leaving your system.

Building on Taxbit, answered.
Two different things come back, and it is worth separating them. The per-jurisdiction XML for CARF, CRS 2.0, DAC7, and DAC8 is generated and filed by Taxbit, so the schema never lands in your codebase. What these endpoints return is your customers' finished tax documents and the tax data behind them, into your own product. You can send data in real time by API or SDK, and in batches by Snowflake, S3, SFTP, or file upload.
By keeping the schema out of your codebase. Taxbit generates the XML for each jurisdiction and handles updates to the schema, the validation rules, and the bilateral agreements on its own side, so a jurisdiction changing its filing format late in the year does not become work for your engineers. You integrate once against the data model rather than once per regime.
Yes. The endpoints are ordinary HTTP APIs that return structured data, so an agent calls the same interfaces a developer builds against, with no dashboard to log into. The tax data returns into your own product rather than redirecting users away.
