Budget: 1500 UAH Deadline: 2 days
I have experience working with parsing and FastAPI, I don't see anything difficult in your task.
Hello, there is a parser, here is its code:
https://github.com/0-EternalJunior-0/-autonewsparser
The developer has disappeared somewhere, and we need to make changes to it. First of all, ensure that it is set up to automatically parse news based on a given criterion, because right now it seems that parsing is initiated only on command. If auto-parsing is not set up, it needs to be configured. The project is deployed on our server, and we will provide access to the executor.
Secondly, here is a list of tasks (for improvement) from our developer regarding the API:
---
New necessary API commands:
1.
A command is needed to request N articles based on an arbitrary WHERE query
it can be named anything, type POST
input data:
{
“where”:{
“field1”:”value1”,
“field2”:”value2”,
“field3”:”value3”
},
“limit”:10
}
the limit value can be anything, but it can be restricted to something, for example, 100… if limit is not provided - return 1 article (by default)
in where any fields can be passed, values are written in string (for universality)... I hope “1” and 1 when querying the database will be considered the same value and will not cause an error… before forming the query, all passed parameters in where need to be checked for existence in the table, for example, using
SHOW COLUMNS FROM articles
or
DESCRIBE articles
and if any field does not exist, return an error
based on the data, a query to the database is formed like
SELECT * FROM articles WHERE field1=’value1’ AND field2=’value2’ AND field3=’value3’ LIMIT 10
all WHERE parameters are combined using AND
and all results with all fields are returned in the API request response… there is no need to remove any fields from the response, all that exist should be returned
2.
A command for arbitrary editing of an article by id is needed
it can be named anything, type POST
input data:
{
“set”:{
“field1”:”value1”,
“field2”:”value2”,
“field3”:”value3”
},
“id”:1
}
before forming the query, all passed parameters in set need to be checked for existence in the table, for example, using
SHOW COLUMNS FROM articles
or
DESCRIBE articles
and if any field does not exist, return an error
it is also necessary to block the transmission of id in the set section, and return an error if id is found there
“set”:{
“id”:”2”
},
this is a clear error, id cannot be changed
based on the data, a query to the database is formed like
UPDATE articles SET field1=’value1’, field2=’value2’, field3=’value3’ WHERE id=1
in the API request response, it is enough to return a 200 code for a successful operation, and another code with a description of the error if something goes wrong
IMPORTANT:
I will be adding fields and indexes to the articles table, so both commands need to work with any fields, current and future, and not be limited to the current table structure.
---
Thirdly, it is necessary to figure out how the delete command works, whether articles that were deleted by the command will be parsed again.
Budget: 1500 UAH Deadline: 2 days
I have experience working with parsing and FastAPI, I don't see anything difficult in your task.
Budget: 1000 UAH Deadline: 3 days
Ready to take it on.
But we need to clarify the order details, write!
I will implement it with a script in Python.
Budget: 2500 UAH Deadline: 1 day
Hello. I am ready to make edits right now. Please message me privately, we will discuss the details and I am ready to start immediately.
Budget: 2000 UAH Deadline: 5 days
Hello, I have been working on developing parsers using different libraries. I suggest we move to private messages to discuss the details of the execution and talk about the deadlines and price.
Budget: 2000 UAH Deadline: 5 days
Hello! I will sort out the code, check if auto-parsing is set up, and if not — I will add it. I will refine the API according to your list: I will implement a request for N articles with filtering and editing an article by ID considering the dynamic structure of the database. I will also study the logic of deletion to avoid re-parsing deleted articles. I am ready to start very soon and will carry out the work without unnecessary questions, just write to discuss the details.
Budget: 5000 UAH Deadline: 7 days
Hello. I have experience with Python. I am ready to collaborate. Please contact me.
Budget: 1500 UAH Deadline: 2 days
Good evening
I am ready to take on your work
Write to me, I will be happy to help with your task
I will do it quickly and efficiently
Good day! Two tasks need to be completed: 1. Develop a product parser from an external website (10–40 thousand items, marketplace) with structured data saved in MySQL for subsequent output in WordPress. 2. Install and configure n8n on VPS, as well as organize AI content processing: prompt setup, text rewriting, image processing, SEO optimization, and text checking for AI detection. You can estimate the cost of completing both the entire project and each task separately. .
It is necessary to perform parsing from Viber channels (Total number - 49 channels, about 80 thousand subscribers).
Good afternoon. I need a keyword parser that outputs results through a Telegram bot. How it should work: Automatic search on 4 websites for keywords that change from time to time. Search queries are sent every few minutes. The words are uploaded in the form of a .txt file. The Telegram bot should have buttons: start bot, stop bot, download file (downloads a file with active keywords), upload file (uploads an edited file with new words). The bot should ignore previously found results, i.e., it should not indicate the same ad twice. The result comes to the bot in the form of a link with a photo, but just a link is sufficient. P.S. searching websites without API, VPS with 6TB and 50 IPs are already available. For detailed information, please contact me via private message.
Task: one dashboard with all business metrics — advertising, funnel, payments, manager performance, revenue planning. Data is pulled automatically via API. Scope: only the YCL direction (employment in Europe). Kommo has other directions — only YCL funnel deals will be included in the repository (filter by funnel/tag to be agreed upon).1. Data Sources (Integrations) Kommo CRM — leads, deals, funnel stages, responsible persons, sources, dates of transitions between stages (must keep history), reasons for refusals, custom deal fields (see point 2). Stripe — payments, amounts, statuses (success/failure/refund), linked to deals. Meta Ads — expenses, impressions, clicks, CPL, leads by campaigns (currently operational). Google Ads, Reddit Ads, LinkedIn Ads — planned; architecture — extensible connectors without core rework. SEO/organic— Google Search Console + GA4. Cross-link: traffic source → lead in Kommo → payment in Stripe (UTM, deal ID in Stripe metadata — propose the mechanism). 2. Mandatory Cuts (Deal Fields in Kommo) Each metric must be filtered/grouped by: Client Citizenship (Kenya, Nigeria, India, etc.). Residence Status: lives in their country / expat (already in Europe). These are two different segments with different cycles, conversion rates, and checks. Country of Placement / Service: Poland, Serbia, Slovakia, Germany (ZAV). Manager, team, traffic channel, period. If any fields are missing in Kommo — the executor indicates which fields need to be added, the client adds them.3. Funnel and Leading Indicators Data by funnel, for each stage — summary and leading metrics: Traffic → lead: leads, CPL by channels + day-to-day expense/click dynamics. Lead → qualification: conversion + first response speed, touches/calls to the manager per day, unanswered leads. Qualification → contract/invoice: conversion + sent offers, stalled deals (days in stage above norm). Invoice → payment: payments, average check + unpaid invoices, failed payments. Summary: revenue, ROMI by channels, run rate to monthly plan. 4. Deal Cycle Average and median lead → payment cycle (business benchmark ~4 weeks), cycle trend over time. Breakdown of cycle by stages (how many days a deal sits at each stage) — to see which stage is dragging. List of deals that have stalled at a stage longer than normal. Cycle breakdown by segments: citizenship, residence status, country of placement, manager. 5. Early Warning of Decline (Key Block) Since the cycle is ~4 weeks, today's leads = payments in a month. The system must: Compare leads/qualifications of the current week with the moving average (4 weeks) and issue an alert if there is a downward deviation: “leads -X%, with a 4-week cycle expect a payment decline in the week [date].” Build payment forecast for 4 weeks ahead from the current pipeline: deals at each stage × historical conversion of the stage × remaining cycle. Highlight in red weeks where the forecast is below plan — with time to react. 6. Additional Payments and Sales Planning In the Kommo deal card, the date and amount of the planned additional payment are stored. The system must: Collect a calendar of upcoming additional payments: total expected, by weeks/months. Highlight overdue additional payments (date passed, no payments in Stripe) — a separate list for follow-up. Calculate the monthly plan as: plan − already paid − scheduled additional payments = how many new sales are needed (in money and in deal units at average check). Weekly schedule: additional payments + forecast of new payments against the weekly plan. 7. Manager Performance Daily snapshot for each manager: touches/calls, conversations, sent offers, payments — for each day separately, with a chart over the period. Progress on personal plan compared to monthly pace (ahead / on pace / behind). Benchmarking with colleagues. 8. Visualization and Roles “Traffic lights” (green/yellow/red) for key metrics relative to norms/plans; progress scales; trend graphs; mobile adaptive. Roles: CEO — everything; COO — entire funnel and managers; team lead — their team; manager — their metrics and position relative to colleagues. 9. Reports and AI Automated reports on schedule (daily summary, weekly report) in the dashboard and/or messenger. Free-form queries (“how has CPL from Meta changed over 2 weeks?”) — LLM over the repository. Alerts in the red zone and according to the rules from points 5–6. 10. Technical Expectations and Staging Repository (PostgreSQL/BigQuery or equivalent) + ETL: Kommo webhooks + periodic synchronization (15–60 min). Frontend: custom or BI tool — propose with justification; requirements for roles, traffic lights, forecasts, and AI queries must be implementable. Stages: (1) audit and metrics map → (2) MVP: Kommo + Stripe + Meta, funnel, traffic lights, roles → (3) deal cycle, early warning, additional payments and plan → (4) SEO, AI reports, alerts → (5) new advertising channels. Payment is staged, with a demo for each stage. In the response, indicate: similar projects (end-to-end analytics), stack with justification, timeline and cost estimates by stages, monthly ownership cost (hosting, tokens, licenses).
A specialist is needed to collect and structure open information about sellers from marketplaces. It is necessary to determine the possibility of automated data collection and to form a database of sellers. In your response, please indicate: which marketplaces you have experience working with; what data you can obtain (seller name, link, categories, rating, number of products, other available fields); examples of similar projects.