ICYMI: new API features, May 2023

Dipro here :crystal_ball: Here’s a quick update with some features we rolled out recently, in case you missed them.

Breaking changes and deprecations

API updates

Marketplace updates

  • Configure what users see after they install your app: Set your post-install flow
  • You can now direct the user to rate your app, manage their billing, and see your app’s pricing with our new Custom URL mechanism
  • 4 more lifecycle webhooks for monetized apps to tell you when a user’s trial has ended or subscription has ended: Learn more here

Any questions or feedback about these topics? Post here and I’ll help :slight_smile:


I’m having trouble defining the column ID with a new column. If I use it once it creates the new column just fine. Then If I delete the column either through the board UI or the API I get this:

“error_code”: “InvalidColumnIdException”,
“status_code”: 200,
“error_message”: “The specified ID already exists or is reserved for a column in this board”,
“error_data”: {
“column_id”: “vizzy_colum”,
“board_id”: 4483473641,
“error_reason”: “invalid_column_id”

I guess the problem is that the column hasn’t really been deleted from the board so that it can be undeleted within 30 days. That’s fine but the new feature would be most useful to me if I can programmatically delete any existing column with the same ID before creating the new one because I’d like my column to have the same ID across all boards.

Hello @Janssen,

Thank you for your feedback! I will share it with our team!


1 Like

Integration apps can now send error messages to the Integration Activity Log , and users can see a history of successful and failed runs.

How do we send error messages when we have to queue mutations because there are more operations than API complexity limits permit to be completed? The API complexity limit reset time means the initial connection will time-out and retry before we can respond with a final status.

  • If we return success, the user thinks something succeeded that may not succeed.
  • If we return an error, the user thinks something failed that didn’t.

Just reiterating that some sort of asynchronous method is needed for the activity log, for example:

  • Post back to the activity log success/failure for an event ID
  • Cache the event ID, respond with a 400 http status to the initial event and all retries, then once complete, respond to retry with the final status.

However, there currently are no event IDs we can even track to know if we’ve seen the event already or not.

Hello @codyfrisch,

Thank you for the feedback. I will share this with the team.

I will let you know if there are updates.