I have a case management system that uses Hasura and would like to add the case number to the users record in a separate crm via a Zapier webhook.
I have two tables, Cases and Users.
The cases table has a foreign key (userID) to the users table. When a new case gets added to the cases table, I would like an event trigger to send the Zapier webhook the contents of both the new cases table record as well as the related users record. Is that possible with Hasura v2.6.1?
Unfortunately the ability to include data from foreign key relationships as part of the event trigger is not currently supported by Hasura.
You'd have to implement your own backend which would process the webhook first and then query extra data before sending it off to Zapier.
I imagine that since you're using Zapier you are probably trying to avoid having a backend in this case to begin with but there's no other option right now
Related
The task is as follows:
There is a list of users from Binance exchange, each user can create an order on the Binance exchange. It is necessary to implement a mechanism for tracking user orders on the Binance exchange through a single connection.
There are a lot of users. A lot of tokens and secret keys. One connection.
I use the node js library "binance-api-node".
But I am ready to hear any solutions to the problem.
Orders sent through the POST /api/v3/order endpoint (client.order() in the library) return a unique newClientOrderId (or you can specify your own and send it with the request payload). You can store it in your app in relation with the order and the user.
Orders that have been created using a different way (e.g. the Binance UI) are a little more complicated. You can receive the list of orders per API key, for example with the GET /api/v3/allOrders endpoint. Each order again contains a unique clientOrderId, and since you know the API key that you used to query these orders, you can make a relation between the clientOrderId and your user.
Note that each Binance account can have multiple API keys and there is no easy way to determine whether two API keys belong to the same Binance account or not. See this answer for more info.
Because each authenticated REST endpoint requires exactly one API key (and some endpoints also require exactly one corresponding secret key to sign the payload), it is not possible to communicate with the API on behalf of multiple API keys in a single connection.
You'll need to make a separate request for each of the API keys.
If I'm wrinting BDD style tests. What would be better practise:
When User A creates new record
Then DB contain correct record
or
When User A creates new record
Then User A can get his new record by some API request
And Admin-user can get this new record by another API request
So should I check internal state of DB or just use API and consider application + DB as a black box?
You should test your application as much as possible using the APIs, as it gives the actual behaviour of your application. In your case, it would be
When User A creates new record
Then User A can get his new record by
some API request
And Admin-user can get this new record by another API
request
Reason being:
By using the Admin API, you are making sure the record is in database and the Admin API behaves as expected
In the future, if your DB changes, which is internal to your application, but the API's behaviour doesn't change then your BDD would work without any issues. In other words, if the devs decide to change DB and not the API, the business service which uses the API is not impacted
If you test only DB, but the Admin API changes, your scenario would pass but the Business service, which uses the Admin API, would fail
The only scenario, you would check the record in DB directly without an API is, when there is no API to verify the record. You shouldn't develop an API purely for BDD. The Admin API should be used in a business service and if this is not the case, you can check the DB record directly (your 1st option).
PS: We have developed a product NoCodeBDD. As the name implies, you can automate BDD without any code using NoCodeBDD. I would love to get some feedback from the community. You can download a free version from www.nocodebdd.com/download
Generally the thing that creates should be the thing that validates. So
if a user (human interacting with a UI) creates
then a user interacting with the UI would validate by viewing the created thing.
if an api client creates
then the api client would validate by examine the response from the create call
additionally the api client could get the thing created using a link in the response
In both cases I would only consider validating via the DB as a temporary measure whilst you are working on the scenario
The docs only covers the case where the payment method is created by the frontend (JS). But there is a risk that the user leaves the website before the frontend sends the information to the backend that the card has been added (and its ID).
In order to make a payment, I need ID of the payment method. I don't want to query Stripe's API for user cards IDs every time before making a payment, so I want to save the payment method ID in my local database. I also want to allow the user to define more payment methods and choose the default one.
Is there a reason you are using the non-recommended workflow you linked to? The most up-to-date version can be found here
Have you checked out using webhook listeners? I use them to create/update my local records.
In the workflow you reference, 3 webhook events potentially fire. First the setup_intent.created event is triggered when your server code generates the SetupIntent and its client_secret. Then, when the user fills out whatever Payment or Card element you instantiate and your frontend code calls the stripe.confirmCardSetup() (or stripe.confirmSetup() in the case of a PaymentElement), both the setup_intent.succeeded and payment_method.attached events will fire.
This last one will POST the payment_method object that was just attached to your customer back to your system. This object will have both the Payment Method ID as well as the associated Customer ID. You can use these to update your local records to map payment methods to customers in your server and avoid unnecessary API calls.
We are using Chatbase for multiple clients that we identify with a different version number.
See my previous question here: Track multiple context for the same Bot
We have a dashboard for all those clients and would like to show them their own data. A bit like Google analytics allows it.
So:
Is an API in the pipeline (I couldn't find any existing resources)
If not, in what alternative way could we get the data to present it?
We have a .csv export that is currently limited to the first 500 rows of your message variations report. It is on our roadmap to increase the scope of this report, however there is no official timeline for release.
Our recommendation for deploying an integration like you described in your message is as follows:
Have the user create a Chatbase account in order to obtain the API key
Have the user integrate their analytics on your platform by providing the API key
Send the messages from their bot to their Chatbase API
Provide the user deeplinks to the Chatbase reports from within your UI
Alternatively, you could configure your bot to send a redundant message to an internal database, or bigquery table to have access to all of your logs.
If you would like access to data you have sent to Chatbase up to this point, please contact chatbase-support#google.com and provide your bot's name and/or api key and we can provide a one-time export.
I am using Stripe and I need to understand how to only process webhooks that are generated by Stripe behind the scenes. When my server sends something to Stripe (new subscription, new individual charge) Stripe will generate events that are sent via the webhooks I provide. Well, I don't need to process those since it will create a mess. I only want to process Stripe generated webhooks in situations like: failed charge at subscription renewal, manual modifications via the Stripe dashboard, refunds generated in the dashboard, etc).
I went through the events generated and I cannot find anything that would make a difference from those my API calls generate or those generated behind the scenes.
Is there something I am missing?
Update
- API call: event has a request id
- Stripe behind the scenes: event has null request_id
- Stripe dashboard: event has a request id (This still remains a problem)
If I discard all webhook events that are not null I will also discard Stripe dashboard events. I need to process Stripe behind the scenes and also Stripe dashboard generated events.
First of all, Stripe currently does not support identifying the incoming webhook event type. Looking in the Dashboard I indeed can see what initiated the event (API, Dashboard or Automatic) but Stripe's people said they don't support it.
However, there is a workaround. For anyone struggling with this I will describe what I did. An automatic Stripe generated event is easy to differentiate. It contains a null request field. Any other type of event will have a request id (ex: re_123h2kj18321hjk3218). The problem remains with differentiating between API and Stripe Dashboard generated requests. Therefore, the solution is to capture the request id for every request generated by the API. Whenever a webhook arrives to your server, you check for the request field NOT to be in the Storage System (DB, etc) OR that the request is null. This means that the event was generated by either the Dashboard or Automatically by Stripe (subscription renewal).
Steps:
Hook into the CurlClient provided by Stripe. Extend that class and
override the request() method. The request method returns the
response generated by Stripe servers. Capture the headers of the
response which would contain a Request-id. Store that in your
Storage (in my case a DB)
In your configuration files you need to specify that Stripe should use your own CurlClient. ApiRequestor::setHttpClient(new CurlClient()); (I've named my CurlClient too but you can name it whatever)
When a webhook arrives, you have three options to identify the type:
Automatic: if the event has a request=null
Dashboard: the request is not null and the request is not in you Storage
API: you're left with one situation. The request is not null but exists in your DB
As you can see, there's quite a lot of work for something really easy. All Stripe needs to do is provide another field in their webhook event name something like request-type with three options (api, automatic, dashboard). They already have this build but they don't allow it to be shown in the webhook event.
On the event object documentation, you'll see the request property documented. This property is set whenever the event came from an API request. Otherwise, if it's null it means there was no API request associated with it and it was what we call an Automatic event in the dashboard.
You need to discard any event where request is not null on your end!