Search API 10 minutes rule?

Hi everyone!

I've noticed in the last few days that the search API returns a "positive" value on a new row (via search API endpoint) exactly after 10 minutes of being created.

Is there any specific docs about this?, or a reason that i'm missing?.

Use Case

Create new row with a value that doesn't previously exist in your sheet

Use Search API and search for that value

Expected Result

Get a positive (non empty 200 response) response

Current Behavior

Get empty (200 yet NO results) response

Only After exactly 10 minutes it does work as Expected

Find more posts tagged with

Accepted answers

All comments

Genevieve P.

Hi @jose albano

I'm not sure that 10 minutes is a set rule; in the Smartsheet API documentation it states that newly created items (such as rows or sheets) will take more time to identify via Search, but there is no set time for how long this could take. Based on this, It sounds like 10 minutes is within expected behaviour.

Please see the blue note at the bottom of this page, here.

Hope this helps!

Genevieve

jose albano

Hi Genevieve,

When i've implemented Smartsheet integration i was totally aware of that info in the docs (yet quite ambiguous, imo), to make sure this was going to work for me i did review this window time, it used to be from 10-20 secs (btw i've ran tests on two different Smartsheet accounts).

Unfortunately somehow this have changed making it a deal breaker for us, in the last few days i've verified this 10mins window with my QA team and also myself.

I'm wondering what would be a workaround for this?, because not even a webhook applies to the process of updating via API a newly created record on a sheet (via your web forms) ... no matter what, in order to get the row id you've to search through API this record, and this window time and the concept of "take more time to identify via search" it's a bummer.

Anyway, thanks a lot for your time, have a good day.

Chris Launey

@jose albano I have run into this as well, and it's really impactful. However, I did find that updated rows show up quickly in search. So I'm thinking of implementing a workaround where I add 20 "blank-ish" rows to bottom of sheet (for example, rows with one hidden column populated with some value not found elsewhere in the sheet, plus standard formulas, etc., only without data columns). So then instead of add_rows, I will:

* do a search for the unique value to find the blank-ish rows

* take the topmost one, do a get_row on it

* update that row object with (1) the data I want to insert (2) overwrite the unique value in the hidden col (3) sibling info so it is correctly placed in sort order

* do an update_rows with that object

* then, add a new blank-ish row with no sibling (which pushes it to bottom of sheet, bottom of other blank-ish rows).

Validation will be - does newly "upserted" row show up (quickly) in search for some value in it? And does it (quickly) not show up in the search for the blank-ish rows? If so, then it works, and performance should be decent. Then it's just figuring out how your data rate of change works for how many blank-ish rows to keep, like you need enough to cover peak use for however many rows you'd add within 10 minutes, so you don't use up all your blank-ish rows.

I'll let you know how it goes.

Sign in to join the conversation!

Quick Links

Component react.discussion.discussions had an error.

ref must be one of: categoryID, siteSectionID, category, category/categoryID, category/name, category/description, category/url, category/allowedDiscussionTypes, locale, siteSection, siteSection/basePath, siteSection/contentLocale, siteSection/sectionGroup, siteSection/sectionID, siteSection/name, siteSection/description, siteSection/apps, siteSection/attributes, layoutViewType, discussionID, commentID, page, latest, sort, sortType, lookupSort, discussion, discussion/name, tags, breadcrumbs, discussionApiParams, serverDraftID, serverDraft.