ASCI API - All Forms

The single consolidated forms test surface for exercising every document (ISF / Quick Entry / QP / BL / Tally In / Tally Out) + master-data endpoint end-to-end. Each tab below is a real working field-by-field form that POSTs to the API and shows the JSON response and HTTP status. Each module also has its own dedicated page (how-it-works + form + endpoints) - see the Home hub for the per-module card index.

What this page is for: this is a developer test harness for the API that UI applications are built on top of. It lets you verify the create / lookup / import / validate / submit contracts directly, with no UI framework in the way. The master-data create endpoints (POST /api/Customers, /api/Manufacturers, /api/Products) are being built in parallel and may return 404 until they land - that is expected.

Setup

API key + base URL used by every request below.

Credentials

API Key

Base URL

Leave Base URL blank to call this same server with relative paths (the normal case). Set it (e.g. https://asci-api.asciofmiami.com) to point the forms at another host. Every request below sends the ApiKey header.

Idempotency Key

Sent on every create / submit POST. Click Generate for a fresh one, or a new one is auto-generated per submit if blank.

Endpoints

Pick a tab. Each form maps to one endpoint family.

ISF

Quick Entry

Tally In

Tally Out

CBP

Customer

Manufacturer

Product

Vendor

Import

Pending Charges

Status

Maps to POST /api/Isf/Submit. Full Importer Security Filing ("10+2") data-entry wizard mirroring the legacy ASCI ISF screens IPISF1-IPISF6: the header (IPISF1) plus commercial entities / parties (IPISF5), tariff lines (IPISF6), bills of lading (IPISF2), containers (IPISF4) and additional references (IPISF3). Each multi-row section is a repeater - use + Add to add rows. reference_no defaults to NEW - the real reference is auto-assigned by legacy at insert time. The customer / carrier / manufacturer / product fields look up your master data live.

1 Entry Header

2 Parties

3 Tariff Lines

4 Bills of Lading

5 Containers & Refs

6 Review & Submit

Step 1 - Entry Header (IPISF1). Who is filing, the Importer-of-Record identity, the transport mode + carrier, and the key dates. ISF is ocean only.

Filing

Reference Number

Metadata (JSON, optional)

Submission Type

Action Code

Importer of Record

ISF Importer Code (Customer)

IOR Qualifier

IOR Number

Importer Reference (your file no.)

Transport

Mode of Transport

SCAC Code (Carrier)

Dates

ISF Filing Date (optional)

Sailing Date (optional)

Step 1 of 6

Step 2 - Commercial Entities / Parties (IPISF5). The "10" in 10+2. Each row is one party with its type, name and address. Use the Customer lookup to auto-pick an existing customer/entity code. ISF-10 requires these party types: MF (manufacturer), SE (seller), BY (buyer), ST (ship-to), LG (stuffing location), CS (consolidator), CN (consignee) and IM (importer of record). ISF-5 instead requires ST + BKP (booking party).

Parties

Step 2 of 6

Step 3 - Harmonized Tariff Lines (IPISF6). The HTSUS tariff number(s) for the goods, one row per line. A harmonized record is mandatory for each Manufacturer (MF) party. Use the Manufacturer and Product lookups to populate the MID / product code; the product lookup is scoped to the manufacturer in the same row.

Tariff Lines

Step 3 of 6

Step 4 - Bills of Lading (IPISF2). At least one Bill of Lading is required to complete an ISF-10. The B/L number is the carrier SCAC concatenated with the bill number, letters and digits only (no spaces or punctuation).

Bills of Lading

Step 4 of 6

Step 5 - Containers (IPISF4) & Additional References (IPISF3). Containers apply only to containerized ocean (mode 11); a container number follows ISO 6346 (4-letter owner prefix + 6-digit serial + 1 check digit). Additional references carry entry numbers, master bills, surety / bond references, carnets, etc. Both sections start empty - use + Add as needed.

Containers

Additional References

Step 5 of 6

Step 6 - Review & Submit. Preview the assembled JSON document, then submit it. The response includes a submission_id you can check below. Server-computed - not sent here: sf_trans_no (the CBP transaction number) is owned by transmission and is computed server-side.

Check status

Submission ID

Calls GET /api/Isf/Status/{id}.

Step 6 of 6

Maps to POST /api/AceQe/Submit. Full ACE Quick Entry: header + ACE flags + multi-row tariff lines (max 5), containers / Box-29 (max 10), commercial entities (max 50), and per-line PGA indicators (max 5). Each multi-row section starts pre-filled with only the populated sample rows; use + Add to add more up to each maximum. The MID / product lookups resolve against GET /api/Manufacturers and GET /api/Products. reference_no is always sent as NEW.

1 Entry Header

2 Commercial Entities

3 Tariff Lines

4 Containers & PGA

5 Remarks

6 Submit

Step 1 - Entry Header. Mirrors the legacy ACE Quick Entry header screen (IPACEQEN1): importer / broker, the required ACE entry, transport, ports / origin / goods, the ACE flags and the bond.

Importer / Broker

Metadata (JSON, optional)

Importer of Record (Customer)

Consignee IRS Number

Broker / Sales Rep (Team)

FIRMS Code

FIRMS City

ACE Entry (required)

ACE Entry Type (required)

Statement Status

District / Port Code

Transport

Vessel Name

Flight Number (Air)

AWB Date or Multi

Ports / Origin / Goods

Port of Entry

Country Subdivision (State)

Default Country Code

Goods Description

ACE Flags

AII Filed

Paperless Flag

No Release Requested

Multi Consignee

Multi Manufacturer

Purchased Indicator

ACH Indicator

GSP / CBI / NAFTA

Bond

Bond Type Code

Bond Notation

Step 1 of 6

Step 2 - Commercial Entities. Mirrors the legacy ACE entity screens (IPACEQEN1A): the commercial entities (consignee, manufacturer, seller, buyer, ...) plus the MID / product lookup helper used to populate a tariff line in the next step.

Commercial Entities (max 50)

Manufacturer (MID) / product lookup

Manufacturer ID (MID) Helper

Product (Description / Code)

Optional helpers: the picked MID / product tariff can be copied into a tariff-line row below. Click Apply MID/product to first tariff line.

Step 2 of 6

Step 3 - Tariff Lines. Mirrors the legacy tariff-line screen (IPACEQEN2): up to five tariff lines, each with its HTS number, country of origin, MID and per-line PGA flags.

Tariff Lines (max 5)

Step 3 of 6

Step 4 - Containers & PGA. Mirrors the legacy container / Box-29 screen (IPACEQEN2A): up to ten Box-29 container lines, plus the per-tariff-line PGA indicators (one per tariff line, max five).

Containers / Box 29 (max 10)

PGA Indicators (one per tariff line, max 5)

Step 4 of 6

Step 5 - Remarks. Mirrors the legacy remarks screen (IPACEQEN3): free-text remarks carried on the entry.

Remarks

Remarks Line 1 (max 35)

Step 5 of 6

Step 6 - Submit & Transmit. Choose the submit mode and submit the Quick Entry, transmit a staged draft, or check submission status.

Submit mode

Submit Mode

direct queues the entry for legacy insertion immediately. draft stages it in the API (status draft, no inbox files written) for later Transmit (POST /api/AceQe/{id}/Transmit). The value is sent as submit_mode inside document.

Transmit a draft

Transmit Draft ID

Releases a staged draft into the legacy queue: POST /api/AceQe/{id}/Transmit. Auto-filled after a draft Submit above. Retry-safe.

Check status

Submission ID

Calls GET /api/AceQe/Status/{id}.

Step 6 of 6

Maps to POST /api/Qp/Submit. Full field-by-field QP (In-Bond / QP301) data-entry form with the in-bond header, plus multi-row repeaters for conveyances, bills of lading and parties. header.customer_code is the only required field. reference_no defaults to NEW - the real reference is auto-assigned by legacy at insert time. The customer / carrier / port lookups resolve your master + reference data live. (Deeply nested container/harmonized/marks detail is not exposed here; use the Test Lab JSON for those.)

In-Bond Header

Reference Number

Metadata (JSON, optional)

Customer Code (required)

In-Bond Number

In-Bond Type

Internal Date

FTZ Indicator

Mode of Transport

Carrier & Ports

Carrier Code (SCAC)

Carrier IRS

Initiation Port (US, Schedule D)

US Port of Destination (Schedule D)

Foreign Port of Destination

Values & Misc

In-Bond Value

Num Conveyances

Operator Code

Log Number

Comments (one per line)

Conveyances

Bills of Lading

Parties

Check status

Submission ID

Calls GET /api/Qp/Status/{id}.

Maps to POST /api/Bl/Submit. Full field-by-field BL (Import Billing Invoice) form with the invoice header plus a multi-row charge lines repeater. header.invoice_no and header.customer_code are required. reference_no defaults to NEW - the real reference is auto-assigned by legacy at insert time. The customer lookup resolves your master data live.

Invoice Header

Reference Number

Metadata (JSON, optional)

Invoice Number (required)

Customer Code (required)

Customer Reference

Transaction Code

Invoice Date

Invoice Description

Shipper / Consignee

Origin / Destination

Entry Number

Entry Date

Airline / Steamship

Arrival / Departure Date

AWB / B-L Number

House AWB

GL Division

Num Pieces

Invoice Value

Weight

Remarks (one line)

Charge Lines

Check status

Submission ID

Calls GET /api/Bl/Status/{id}.

Maps to POST /api/TallyIn/Submit (DOC_TYPE TI, channel tally.in.create). Field-by-field Tally In (FTZ warehouse receipt) form with a receipt header plus a multi-row lines repeater (each line: product_code + pieces required). receipt_no follows the NEW convention - blank / NEW means ASCI assigns the next receipt number at insert time. Supplier / shipper / consignee lookups resolve your customer master live.

Receipt Header

Metadata (JSON, optional)

Bonded / Foreign

Receipt Number

Supplier Code

Supplier Name

Shipper Code

Consignee Code

Carrier Name

Pro / Freight Bill No

PO Number

Reference No

Destination

Import Date

Date In

Location

Remarks

Receipt Lines

Tally In rides the generic inbound pipeline; the Submit response carries the submission_id + status_url. (There is no dedicated per-submission Tally status endpoint - the run-locked IPAPIGET consumer drains the queue.)

Maps to POST /api/TallyOut/Submit (DOC_TYPE TO, channel tally.out.create). Field-by-field Tally Out (FTZ withdrawal) form with a withdrawal header plus a multi-row lines repeater (each line: product_code + qty_ordered required). tally_out_no follows the NEW convention - blank / NEW means ASCI assigns the next number at insert time. Depletion (FIFO by date-in) is performed server-side. Customer lookups resolve your customer master live.

Withdrawal Header

Metadata (JSON, optional)

Tally Out Number

Type

Type 0216 (Activity)

PO Number

Customer Code

Sold-To Code

Ship-To Code

Operator

QP / Consumption

Order Date

Requested Date

Withdrawal Lines

Tally Out rides the generic inbound pipeline; the Submit response carries the submission_id + status_url. (There is no dedicated per-submission Tally status endpoint - the run-locked IPAPIGET consumer drains the queue.)

Create a customer master record: POST /api/Customers (find-or-create write-through: sync upsert to the API store + enqueue legacy CU write). The 6-char code is client-supplied (broker codes are meaningful).

Find existing

GETs /api/Customers?code=&name=. Click a row to load it into the form.

Create

Code (required)

ID Qualifier

ID Number (IOR)

Name

Address 1

Address 2

City

State

ZIP

Country

IRS Number

Surety

Bond Type

Continuous Bond Number

Default Manufacturer ID

Create a manufacturer master record: POST /api/Manufacturers (sync upsert + enqueue legacy MF write). Key is the 16-char real mid.

Find existing

GETs /api/Manufacturers?mid=&name=&address=. Click a row to load it.

Create

MID (required, 16)

Name

Address 1

Address 2

City

State

Postal Code

Country

Create a product master record: POST /api/Products (sync upsert + enqueue legacy PR write). manufacturer_id is optional - unlinked products (no MID) are supported. The product_code is an API-only convenience alias.

Find existing

GETs /api/Products?code=&description=&manufacturer_id=. Click a row to load it.

Create

Manufacturer ID (MID, optional)

Product Code (optional)

Description (required)

Tariff Number

Create an A/P vendor master record: POST /api/Vendors (idempotent store upsert keyed by tenant + code; scope ipjson.submit). There is no legacy vendor writer yet, so this is a store-only upsert. The code is the legacy AP_VEND_CODE. Backs the Pending Charges payee.

Find existing

GETs /api/Vendors?code=&name=. Click a row to load it.

Create

Code (required)

Name

Vendor Type

Contact

Address 1

Address 2

Address 3

City

State

ZIP

Country

Overseas

Phone Area

Phone

Fax Area

Fax

Terms Code

Form Code

GL Acct (A/P)

GL Acct (Expense)

Our Acct No

Recipient ID (1099)

Pay-To Name

Pay-To Address 1

Pay-To Address 2

Pay-To City

Pay-To State

Pay-To ZIP

Pay-To Country

Pay-To Attn

Pay-To Phone

Bulk-import master data into the API store: POST /api/Import/Entities (idempotent upsert). Choose a mode and which entity groups to include, paste the JSON body, and Submit. The response is an ImportReport (inserted / updated / duplicates / errors).

Mode

Customers Manufacturers Foreign Entities Vendors

The toggles control which top-level arrays are forwarded from the body below. Unchecked groups are stripped before POST so you can test partial imports without editing the JSON.

Request Body (JSON)

Push a batch of pending charges (legacy IPCHR) into the API billing store: POST /api/Charges/Import (idempotent UPSERT on (ref_no, seq_no); scope ipjson.submit). Direction: ASCI → API. Charges are settled through our payment provider - the outbound send is a stub pending the provider's API spec; routes stay provider-neutral. See Pending Charges for the full endpoint reference and the settlement writeback feed.

Read existing

List GETs /api/Charges?status=&vendor_code=; Settlements GETs /api/Charges/Settlements (the legacy writeback poll feed). Both need queue.read.

Import (push a batch)

Mode

Charges Body (JSON)

CBP Communication (CBPCOM). Transmit a built CATAIR message to U.S. Customs and track every reply. Cert vs Production is a controlled setting (Certification is active by default). ASCI builds the CATAIR (after inserting the MKEYED entry and generating the reference); this is the API-driven transmit + reply-capture path. Needs an ApiKey with cbp.submit (transmit) / cbp.read (view).

Active environment

Transmit a CATAIR message

Channel

Reference No

Filer Code

CATAIR

Submissions

Filter channel

Submission detail (status, replies, ISF/entry/bill numbers)

Channel

Submission ID

What CBP returns: for an ISF, the reply carries the isf_number (CBP ISF Transaction Number), the bill_no (bill of lading), and an accept/reject status (ISF ACCEPTED / REJECTED). For a Quick Entry, the reply carries the assigned entry_no. Every reply (success and failure) is captured with its CBP condition codes; the operator view is the Manager's CBP Comm Manager.

Generic status checker. Pick a document type and paste a submission_id; this GETs the matching /api/{Type}/Status/{id} endpoint and shows the BBx-side lifecycle (submitted → picked_up → processed).

Document Type

Submission ID

What happens after a Submit

After Submit: the API writes the JSON + .txt to the tenant inbox and a typed SQLite row. In the BBx menu, run Import Procedures > Fetch Data from Web (program IPAPIGET) to pick it up, then use the Status tab; the state moves from submitted to processed and bbx_reference_no is populated. Customer / Manufacturer / Product creates enqueue a legacy CU / MF / PR write that runs ahead of the document that references it (FIFO ordering guarantee).