TaxTrex API and Webhooks
If you already have your own screens, use TaxTrex for the documentation and calculations underneath. The headless option lets your system keep its own interface while TaxTrex works behind it.
What it is
The headless option lets the host system keep its own user interface while TaxTrex handles R&D documentation and calculations behind it, through an API and webhooks. An API is how one piece of software asks another to do something or to supply information. A webhook is how one piece of software tells another that something has happened. Together they let your system and TaxTrex stay in step without TaxTrex's screens appearing at all. TaxTrex is a Swanson Reed product, and the options here are proposals until Swanson Reed confirms them.
How it works
- 1
Connect
Your system calls the TaxTrex API to create projects, record answers and request results.
- 2
Receive events
Webhooks tell your system when something changes, such as a survey being completed or a claim pack being ready.
- 3
Show results
Your interface presents the data in your own design, using your own components.
- 4
Keep in step
Your system and TaxTrex stay consistent, because each tells the other what has changed.
What you get
- Full control of the interface.
- TaxTrex logic without the TaxTrex screens.
- A way to fit R&D documentation into an existing product.
- Data in your own database, if you choose to keep it there.
Embedded portal or API?
Both are proposals until confirmed by Swanson Reed.
| Consider the API if | Consider the portal if |
|---|---|
| You have developers and want control of the experience | You want to launch quickly with less technical work |
| Your system already has its own screens for clients | You are content to use TaxTrex's screens inside yours |
| You want R&D data inside your own reporting | You want the product to handle reporting |
| You expect to build features around it | You expect to use it as it comes |
What developers will want to know
Developers will ask the usual questions: how requests are authenticated, what the data structures look like, how errors are reported, what rate limits apply, how webhooks are secured and retried, and where documentation lives. These details are confirmed with Swanson Reed, and this site does not state them. We can describe the approach in general terms, and we can help you prepare questions for Swanson Reed so that you get what you need before committing to build.
A worked example (illustrative)
This scenario is invented. A software company that serves accounting firms has its own client portal and a development team. It wants R&D documentation to be a native feature. Its developers use the API to create a project in TaxTrex whenever a user adds one in the portal, and to send each survey answer across. A webhook tells the portal when a claim pack is ready, and the portal shows a button. Users never see a TaxTrex screen. The company brands the feature as its own. It takes the developers longer than an embedded portal would, but the result fits their product precisely.
Responsibilities
Using the API means you take on more of the work: building and maintaining the screens, handling errors gracefully and keeping your integration working when the API changes. It also means you are responsible for how information is presented, including what is said about the credit. Keep the standard disclaimers, avoid wording that promises outcomes and make clear that a licensed professional reviews claims. Agree with Swanson Reed what wording you may use.
Limits
The API route needs developers and ongoing maintenance. It does not change what the product does: it does not decide eligibility, give tax advice or file returns. Availability, endpoints, limits and terms are proposals until confirmed by Swanson Reed. Please do not start building before you have them in writing.
Integrations, review tiers and partner pricing are proposals until confirmed by Swanson Reed.
Questions to ask Swanson Reed before building
Get answers in writing before you commit developer time.
- Is there written documentation, and is it kept up to date?
- How are requests authenticated, and how are credentials managed?
- What are the usage limits, and what happens when they are reached?
- How are webhooks secured, retried and monitored?
- How are changes to the API announced, and how long are old versions supported?
- Is there a test environment?
Planning the build
Treat an integration as a small project. Decide what your users need to do, then map each action to what the API provides. Build the smallest useful version first, such as creating projects and receiving survey answers, and test it with real data. Add features after that. Keep a log of problems and of what Swanson Reed says about them. And set aside time for maintenance, because an integration is something you keep, not something you finish.
Keeping the integration healthy
Once live, an integration needs watching. Log failed calls and failed webhook deliveries, and decide who looks at them and how often. Test after any change on either side. Keep credentials secure and rotate them as your security policy requires. Plan for versions: if the API changes, you will need time to adapt. A short runbook, saying what to do when something breaks, is worth writing while the system is fresh in the developers' minds.
API questions
Is there public API documentation?
Confirm with Swanson Reed. We do not publish API details on this site.
Can we use it in a test environment first?
Ask Swanson Reed. Arrangements are confirmed with them.
Who supports developers?
That is part of the terms to confirm with Swanson Reed.
Can we start with the portal and move to the API?
That is the intention, but it is a proposal. Ask what is currently possible.
Please note: Estimates and drafts are prepared by software for review by a licensed CPA or enrolled agent. This is not tax advice.
Find out what AI would cost you
Book a free call. We will map three opportunities and give you a rough idea of cost and payback.