LoginStart free trial

UI workflow map

The API and product interface are two doors into the same controlled workflows. This map shows what an operator sees, what an integration can call, which evidence is retained, and where authority deliberately stops.

Begin with the UI when a reviewer needs to inspect or approve work. Begin with the API when a source system must calculate or synchronize at transaction speed. Both paths remain scoped to organization, location, entitlement, environment, and actor authority. See the endpoint reference for operation details and product documentation for screen-level concepts.

1. Developer Console and API keys

UI path
Sign in → Developer Console → Keys, request log, usage, webhooks
Evidence retained
Key prefix, scopes, environment, creation/rotation/revocation audit, request ID, response status, and webhook delivery attempts.
Authority boundary
A key authorizes only its scopes, tenant, location, and environment. Secrets must remain outside prompts, source code, URLs, and logs.

Operator flow

  1. Choose sandbox or live
  2. Create a least-privilege key
  3. Copy the secret once
  4. Rotate or revoke without reusing a secret
  5. Inspect request IDs and delivery history

API relationship

  • GET /api/v1/config
  • All authenticated /api/v1 operations
  • Webhook subscription and replay control plane

2. Sales Tax Engine

UI path
Dashboard → Sales Tax Engine → Cockpit, Data sources, Calculation, Apply
Evidence retained
Original inputs, normalized address, jurisdiction path, content source, line money, marketplace responsibility, idempotency key, provider binding, and lifecycle events.
Authority boundary
A calculation is read-only. Applying tax or mutating a provider draft requires separate provider authorization and an idempotency key; unresolved responsibility fails closed.

Operator flow

  1. Connect or upload the source transaction
  2. Review address, jurisdiction, product, exemption, and marketplace facts
  3. Calculate or quote
  4. Apply only to an authorized provider draft
  5. Commit the completed document
  6. Follow refunds, voids, and adjustments

API relationship

  • POST /api/v1/addresses/resolve
  • POST /api/v1/tax/calculate
  • POST /api/v1/tax/quotes
  • POST /api/v1/tax-engine/provider-quotes/apply
  • Transaction lifecycle operations

3. Use Tax Engine and purchasing review

UI path
Dashboard → Use Tax Engine or Purchasing Tax Compliance → Data sources, Calculation, Review, Write-back
Evidence retained
Source document, extracted fields, expected-versus-charged tax, reason code, confidence, reviewer action, and write-back confirmation when configured.
Authority boundary
No amount posts silently. Calculation and preparation do not grant ERP journal authority; write-back requires an approved profile and reviewer action.

Operator flow

  1. Load supplier invoices or purchase lines
  2. Compare vendor-charged with expected tax
  3. Review exemptions and use location
  4. Approve an accrual or correction
  5. Write back only through a configured accounting profile

API relationship

  • POST /api/v1/tax/calculate
  • Batch calculation operations
  • Document and transaction read operations

4. Sales data upload and mapping

UI path
Upload Center → Sales transactions → Inspect → Map → Validate → Import
Evidence retained
File hash, source headers, sample rows, mapping choice, confidence, warnings, target location, row counts, and import result.
Authority boundary
Low-confidence or incomplete mappings require review. Missing fields remain missing; the importer does not substitute zero or infer a filing fact.

Operator flow

  1. Select organization and location
  2. Inspect headers and representative rows
  3. Review deterministic and AI-assisted mapping suggestions
  4. Resolve missing required fields
  5. Preview normalized output
  6. Import idempotently

API relationship

  • Batch and transaction operations where an API replaces file upload

5. Accounting, billing, and ERP connections

UI path
Sales Tax Compliance → Data Sources → Set up an integration → Verify → Period Review
Evidence retained
Organization and location scope, provider profile, encrypted credential types, verification status, source period, provider object version, immutable source snapshot, row counts, sync metrics, and safe errors.
Authority boundary
QuickBooks and Stripe expose only their implemented profiles. SAP S/4HANA Cloud, Oracle Fusion Cloud, and NetSuite are read-only Period Review adapters; they do not calculate in real time or write back. Adapter availability is not a tenant-connected claim.

Operator flow

  1. Choose the provider for the active organization and location
  2. Enter the tenant base URL and least-privilege credentials
  3. Verify a bounded read
  4. Choose a date range
  5. Queue a read-only Period Review
  6. Inspect sync status, source evidence, normalized rows, and readiness blockers

API relationship

  • GET /api/sales-tax-compliance/external-provider-capabilities
  • POST/PATCH /api/sales-tax-compliance/external-connections
  • POST /api/sales-tax-compliance/external-connections/{id}/verify
  • POST /api/sales-tax-compliance/external-connections/{id}/sync
  • GET /api/sales-tax-compliance/external-sync-runs

6. Nexus Monitoring

UI path
Sales Tax Compliance → Nexus Monitoring → Summary, map, and all-state status
Evidence retained
Effective-dated threshold, dollar and transaction numerator, calendar window, data-through date, physical-nexus facts, status, and review notes.
Authority boundary
Monitoring is evidence and decision support, not legal advice or state registration. Stale or incomplete data is never represented as zero exposure.

Operator flow

  1. Confirm the selected organization and period
  2. Review the data-through date
  3. Compare current and prior-year sales and transaction counts
  4. Investigate approaching or met thresholds
  5. Record physical nexus facts separately
  6. Coordinate registration outside this workflow

API relationship

  • Committed transaction inputs feed monitoring; nexus status remains a product workflow rather than a public mutation endpoint

7. Marketplace facilitator review

UI path
Sales Tax Compliance or Sales Tax Engine → Marketplace operations → Responsibility and statements
Evidence retained
Channel account, effective dates, statement hash, responsibility fields, jurisdiction rule version, contradiction flags, and reviewer outcome.
Authority boundary
A provider name never decides responsibility. Unknown or contradictory facts block application and return treatment until reviewed.

Operator flow

  1. Identify channel account and effective period
  2. Review merchant-of-record, collection, remittance, reporting, seller, and facilitator roles
  3. Attach facilitator statements
  4. Resolve contradictions
  5. Apply jurisdiction rules to nexus and return treatment

API relationship

  • Calculation and transaction requests carry explicit marketplace responsibility context

8. Returns Centers and filing-ready handoff

UI path
Dashboard → Sales or Purchasing Returns Center → Period → Package → Review
Evidence retained
Period, jurisdiction, source totals, package hash, form/version, blockers, reviewer, approval time, download event, and externally supplied filing confirmation.
Authority boundary
Prophit.ai prepares and records. The customer submits the return and remits tax. No API operation files a return, moves money, or represents the customer before an authority.

Operator flow

  1. Choose jurisdiction and filing period
  2. Reconcile source totals and blockers
  3. Generate the supported worksheet, return package, or portal-upload artifact
  4. Review and approve
  5. Download or open the customer-operated e-file handoff
  6. Record the externally completed filing event

API relationship

  • Returns preparation and package-download operations
  • External filing-event record operation

9. Service-provider portfolio

UI path
Provider Console → Clients → Client context → Data and return preparation
Evidence retained
Provider engagement, external client reference, canonical tenant ID, request context, user/provider actor, artifact hash, and immutable audit events.
Authority boundary
A provider credential never implies access to every tenant. Every tax-data request requires an active, authorized client context.

Operator flow

  1. Onboard or select a client
  2. Send every tax-data request with explicit client context
  3. Prepare client-scoped returns output
  4. Download artifacts
  5. Record external events without crossing tenant boundaries

API relationship

  • GET/POST/PATCH /api/v1/provider/clients
  • Client location operations
  • Client-context tax and returns operations

10. Tax Notices and augmented export

UI path
Sales Tax Compliance → Notices → Inbox, response worksheet, augmented bundle
Evidence retained
Source document hash, OCR status, category and confidence, due date availability, immutable status events, response worksheet, export scope, per-dataset availability, and authenticated record links.
Authority boundary
The workflow prepares correspondence evidence and a response worksheet. It does not send an authority response, file a return, remit money, or expose raw storage URLs.

Operator flow

  1. Upload a notice document or forwarded .eml
  2. Review OCR and classification status
  3. Confirm due date and priority
  4. Prepare the response worksheet
  5. Download the source behind tenant authentication
  6. Build a scoped evidence ZIP for customer review

API relationship

  • Authenticated /api/notices operations
  • GET /api/exports/augmented-bundle for an authorized location or an explicit admin/provider organization scope

Choosing the right surface

  • Use the UI for investigation, mapping, exception resolution, approval, and filing-ready package review.
  • Use the API for deterministic calculations, source-system lifecycles, provider portfolios, and repeatable system-to-system exchange.
  • Use both when automation prepares the work and a named reviewer owns the material decision.
  • Keep external actions separate: return submission, remittance, registration, authority representation, and unconfigured write-back do not arise from preparation authority.
PreviousQuickstartNextAuthentication