Unified expression schema

What's new

The spec used to describe expressions with five overlapping schemas: Expression and MathExpression for items and campaigns, and ExpressionSchema, MathExpressionSchema, and TokenSchema as copies for the News API. They are now a single recursive Expression:

• tokens — a list of Token objects (type and value), as before.
• name — optional. It was required on MathExpression.
• variables — a list of nested Expression objects.

MathExpression, ExpressionSchema, MathExpressionSchema, and TokenSchema are removed. The TokenType enum also gains a function value.

Impact

The JSON shape of an expression hasn't changed, so existing payloads still validate. Two details did change: quantity_expression no longer requires name, and any expression can now contain a function token.

Changes

Resource	Change
create_item, update_item, bulk_update_items, bulk_create_or_update_items, get_items, get_item, and every endpoint that returns nested items	quantity_expression now uses Expression instead of MathExpression, so name is optional
get_news_list, get_news_post, create_news, update_news, bulk_update_news	requirements_expression now uses Expression instead of ExpressionSchema
get_campaigns, get_campaigns_by_ids, get_campaign, create_campaign, update_campaign, update_campaign_graph	Campaign attribute variables are now Expression objects instead of MathExpression
All 59 endpoints that carry expressions	Token type accepts function
Components	Removed MathExpression, ExpressionSchema, MathExpressionSchema, and TokenSchema

Upgrade

• No change is needed on the wire.
• Clients with generated models should regenerate. Code that imports the removed schema types needs to switch to Expression and Token.
• Clients that decode token type into a closed enum should add function.

Need help?
Contact our integration team at [email protected]