Hi Folks,
Posting this here as our account rep asked us to do so. I have been working to start implementing the API for our companies use case. Basically we are looking to have a list of backlogged parts that we need, and have the subscription system notify us when parts become available on the store so that we trigger an order via the API.
The two obvious ways to do this would be
- Use the subscription push API
- Periodically poll the store/products API
Nominally, event driven is better (less traffic for both TI and for us, and if the subscription API works correctly, ideally less latency between the "inventory has been added" and our endpoint getting notification).
So, I have set up a subscription for on of the parts we use (redacted here, but I will provide it to TI in a DM if requested). It is active. If I query my subscriptions, I get:
$ curl -X ‘GET' 'https://transact.ti.com/v2/store/subscriptions/inventory’ \
-H 'accept: application/json’ \
-H 'Authorization: Bearer XXXX’
[
{
"tiPartNumber": "OPAXXXXX",
"requestedQty": 1000,
"currency": "USD",
"autoSubscribe": true,
"expirationDate": "2023-04-08",
"creationTs": "2023-03-09T06:36:37+0000",
"lastUpdatedTs": "2023-03-09T06:36:37+0000"
}
]
Which shows that I have an active sub (created on 2023-03-09). I have the "Inventory subscription push API” implemented on our server and set up in our TI API account. If I run the test for our API endpoint with:
/store/subscriptions/inventory/test
It works, and I get the test notification.
You folks added more than 1000 parts to the TI store sometime before I checked inventory manually on 3/15 (IDK exactly when or how many; when I checked the part on 3/15 in the early afternoon, there were > 1000 parts in stock with no ordering limits.)
I would have expected that inventory subscription push notification to fire, but it did not (I have been logging all notifications I receive).
I manually purchased all the available parts via the webstore.
After I purchased, the API said the parts were available for order for some time (at least 10 minutes, perhaps more) after I had received the order confirmation. Eventually, when I checked again hours later, the inventory changed from what it had been originally when I purchased to 2000, with an order limit of 50pc.
The upshot of this is that even if I build an auto-order system based on the subscription API, it appears I will not get timely notifications (at least as the system is working right now). That means that it is not (currently) worth building anything based on the subscription API.
The only thing that has a chance of working is simply polling the API continuously. IDK how often this polling should be done (once a minute? once an hour? once a day?)
In addition, even polling seems to risk being told that parts are available for order when they have already been committed to another customer. It seems like there is too much latency in the system.
What happens if we order parts when the system says that there are parts in stock, but they have already committed to another customer’s order (like what would have happened to someone else ordering when the system said that there were X parts available, but they had already been committed to our order)? Will we get an error? Will we get an order confirmation, but then it gets cancelled later? It is not clear to me how this will work...
We are willing to spend the time to implement the API, but as with all companies, we have to target our engineering resources at efforts that will provide ROI. If the API doesn't reliably notify or update, I am concerned that we will invest a bunch of effort for no real benefit.
As I said, if someone from TI wants to investigate details, I can provide the P/N, account, and order info via a DM.
