Delete an existing CheckoutCustomField in Jumpseller

What this operation does

Delete an existing CheckoutCustomField.

• DELETEChanges data · Checkout Custom Fieldsapi.jumpseller.com/checkout_custom_fields/{id}.json

How HumDay uses it

1. You describe the outcome. Not this operation by name — what you want to happen. HumDay works out which operations it needs.
2. The contract names it. Before anything is built, you see exactly which Jumpseller operations the program may use, and this is one of them.
3. You approve access. Because this one changes data, it cannot run until you have explicitly granted it.

Other Jumpseller operations

• Create a new OrderPOST · changes data
• Create a new CustomerPOST · changes data
• Create a new PagePOST · changes data
• Create a new Order History EntryPOST · changes data
• Create a new CustomerCategoryPOST · changes data
• Update a new CustomerPUT · changes data
• Adds Customer Additional Fields to a CustomerPOST · changes data
• Create a new HookPOST · changes data

All 142 Jumpseller operations

Questions

Can HumDay delete an existing checkoutcustomfield in Jumpseller?

Yes. This operation is published in Jumpseller's own API description, so HumDay can use it without a hand-built connector — once you have approved it for your automation.

Will this change my Jumpseller data?

Yes — this is a DELETE operation, so it changes something in Jumpseller. HumDay holds anything that writes behind an approval you grant explicitly, and the contract you approve says what it may touch.

Do I need to write code?

No. You describe the outcome you want in plain words. HumDay agrees a contract with you, writes the program, and shows you a proof run before anything touches your Jumpseller account.

Where this came from

Read from a published API description for Jumpseller at api.jumpseller.com/swagger.json. The description above is the provider’s own wording, not ours. Last published 2021-08-23.