I want to get the item name, item created by, item assigned in webhook url.
like in webhook https://api.domain.com/v1/message?appname={{app_name}}&itemname={{item_name}}&itemassignedto={{item_assigned_to}}
is there anyway like this?
This is not possible to do in that way. When the webhook is invoked you will only get an item_id as a POST parameter. Use this to make an API request to get the item the webhook was called on and you get the exact same result.
Related
I need to know what am I doing wrong with my integration. I will explain first our main goal.
We need to detect new synced projects or created projects on Everhour API using a webhook.
Use that webhook to trigger automation on Zapier and do other APIs we need to do.
The process of creating a webhook using their API is like this:
Use the create a webhook endpoint ( link )
Pass the custom webhook(I created on Pipedream with custom header)
The Everhour API requirements say that I need to reply back a custom header of "X-Hook-Secret ":
So far I have created a webhook on Pipedream which you can create a custom header response see reference here:
This is the request body from the Everhour API to create a webhook, I passed in the Pipedream's custom webhook created.
Now, the problem is when I create a new project on Everhour the webhook doesn't get triggered. I don't know if it's because of the custom webhook from Pipedream that I miss something or else others.
Any useful tips will be a huge help.
I need a Dialogflow agent to query multiple times a REST webservice (endopoint) outside the Google Cloud.
Documentation, tutorials, everything points to enable fullfillment and on the intent that will trigger the network request, enable "webhook call for this intent".
Well, on the fulfillment panel, enable Webhook, and paste custom endpoint URL, and pass parameters from the context, auth parameters (to the endpoint, ), headers...
However when calling the intent, I noticed no network activity related to the webhook. So, the custom webhook is not invoked. Which is the first point of my question: How to trigger or make that when an intent is succesfully matched, the desired webhook is invoked.
I have no issues with the backend, endpoint, it's OK, works well via Postman, curl,... from any service.
My real issue is why, my custom webhook is not triggered, say no network activity, no fetch, no ajax, no nada. NO webhook request. I need to see at least a network request to the custom endpoint, no matter the type of response or the payload, this is not the matter of my question. Just how to send custom webhooks requests and send many, triggered for different intents. As far as I can see, only one custo webhook/endpoint is available.
Should it be invoked via events?
It sounds like you have several questions in there. Let's try to break them down.
Why isn't my webhook being called?
You don't show screen shots of your Intent or your configuration, but the most common reason why a webhook isn't called is because, although you have set the fulfillment URL, you haven't specifically enabled it for the Intent.
Make sure in the "Fulfillment" section at the bottom of your Intent, you have turned on "Enable webhook call for this intent".
That's good for one Intent. How do I set a different webhook for each Intent?
You don't.
Each Dialogflow agent can only call one webhook. The information sent to that webhook includes the Intent Name that is triggering it, and the webhook is expected to take appropriate action based on this name. The exact function that the webhook calls is sometimes referred to as the Intent Handler.
What if I need to?
Then you'll need to write a layer that handles the fulfillment dispatch from Dialogflow, verifies the request, extracts the Intent Name and other parameters from the JSON that is sent, makes the call to the other REST endpoints as appropriate, get the result back, and possibly format the results back to Dialogflow.
Can events help with this?
I don't see how.
Intents that are triggered by an Event work the same way as those that are triggered by user phrases. All Events in an agent still call the same webhook passing the same information.
Events are really most effective to represent exactly that - a user action rather than a the spoken or typed input from a user.
I'm using the docusign api and am having some trouble with a query string param. Basically I'm trying to grab the recipient information of an envelope along with the status of the envelope in a single call.
I am able to grab each of information individually with the following api calls and they both work
1.) Envelope endpoint (has a status field with overall envelope status such as Signed, Voided, Declined, etc...):
https://na2.docusign.net/restapi/v2/accounts/:accountId/envelopes/:docusignEnvelopeId/
2.) Envelope/recipients endpoint (has information regarding recipients)
https://na2.docusign.net/restapi/v2/accounts/:accountId/envelopes/:docusignEnvelopeId/recipients
However, I'm trying to see if I can grab these information all within one API call. According to the docs here for the general envelope endpoint, I think I should be able to with a query param
https://developers.docusign.com/esign-rest-api/reference/Envelopes/Envelopes/get#request.
Under the include Optional Query Parameters section, there's a param for "include" which says I can grab recipients from the 1st endpoint. "Specifies additional information about the envelope to return. Enter a comma-separated list, such as tabs,recipients. Valid values are..."
I've been trying to modify the first endpoint with this include param to look something like this...
https://na2.docusign.net/restapi/v2/accounts/:accountId/envelopes/:docusignEnvelopeId?include=recipients
But I have been unable to have recipients show up as well. Was wondering if I'm just typing in the param wrong or if this is not available anymore. Any help would be appreciated!
Thanks :)
The include parameters were added in v2.1 of the eSignature API, so they don't work in v2. Changing your URL to https://na2.docusign.net/restapi/v2.1/accounts/:accountId/envelopes/:docusignEnvelopeId?include=recipients should return the recipient info.
I'm looking to use the DocuSign REST Java API to request a signature from a template, but I'd like to include a specified request id string that I can retrieve via the envelope after the signer completes the form.
Envelope.setTransactionId("") sounded like what I wanted (though I'd rather have something permanent instead of just valid for 7 days as mentioned in the docs), so as an example I called:
envDef.setTransactionId("TRANS12345");
But when I sign the test Envelope and then query it with getEnvelope(...) and call getTransactionId() I get null.
Can anyone point me in the direction of how to properly retrieve the transaction ID, or if there is a better way of adding a permanent specified ID to a signing request?
You can use Envelope Custom Fields aka Document labels to specify additional metadata for an envelope.
See this answer for more information.
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!