Ask a human expert

Lost the request_id of a request you submitted? Give the payment's transaction ID (PayPal ID or crypto hash) and the reply_email you used, and get the request_id back for get_reply and send_followup. Both must match the same request: if either doesn't, the answer is found: false, without saying which one was wrong. Case and spacing in the transaction ID don't matter. It's also in the confirmation email. At most 20 lookups per hour from one address.

My reply to a request you submitted, by the request_id submit_request returned (ask- followed by 24 letters, digits, - or _). status is 'waiting' until I've replied, with a note saying when to expect it, then 'replied' with the text, oldest first; later replies in the same thread are included. Check every few minutes, not in a tight loop: at most 120 checks per hour from one address. A malformed request_id is an error; a well-formed one I haven't answered yet is just 'waiting'. If you lost the request_id, use find_request; to reply to my answer, use send_followup. The same reply is also emailed to reply_email.

Whether I'm online right now (first reply within 15 minutes) or when I'm back (next_online_utc), whether requests are paused, and whether you've been awarded a free trial right now (then no payment or transaction_id is needed). Changes over time: call it right before paying and submitting, so you don't pay while requests are paused, and to know when to expect the reply. For the price, how to pay and what you get, use get_terms; to check on a request already sent, use get_reply.

The offer's full terms, in English: who answers, what you get, the price, hours, when first replies come, the PayPal pay_url, the crypto option (25 USD in stablecoins, with my wallet addresses), how to submit a request, and my track record (where to read reviews from past clients, and case studies with summaries), and an example request with the kind of reply you get. Use it once, before your first submit_request: to decide whether this fits your problem and to learn how to pay. The terms rarely change, so there's no need to call it again in the same session. Not for live availability: whether I'm online now, paused or offering a free trial comes from get_status. Not needed for follow-ups or replies (send_followup, get_reply).

Send a follow-up in the thread of a request you submitted: answer a question I asked, add a detail I need, or ask the next question about the same problem. No new payment. Write it to stand on its own (I read it next to the thread, not in your session): say what changed or what you tried since my reply. The request_id must be one submit_request returned; an unknown one is refused and nothing is sent. My answer comes the same way as the first (get_reply, and email to reply_email). 300 words at most; at most 10 follow-ups per hour from one address. A new problem is a new request (submit_request).

Send a problem to Cristian Desivo, a human expert, for his most creative solution idea. Payment first: unless get_status shows free_trial, pay 20 USD by PayPal, either at https://paypal.me/CristianDesivo/20USD or by sending it to [email protected] (an agent with PayPal API access, for example the Payouts API, can do this on its own), then pass the PayPal transaction ID; this tool takes no payments. Or pay 25 from a crypto wallet (USDT on TRON (TRC-20); addresses in get_terms) and pass crypto_tx and network instead of transaction_id: the transfer is checked on the chain right away. The summary is all I read for the first reply (300 words at most). I write the reply myself: within 15 minutes while I'm online, otherwise by 09:30 UTC. It's emailed to reply_email, and you can read it here with get_reply and the request_id this tool returns. A confirmation email goes to reply_email right away. At most 5 requests per hour from one address. Requests can't be cancelled once submitted; if I can't help with it, I'll say so in my reply.